Bug in Steve Waring's HTTP client?

Hi All

Following advice from this group, I have been using Steve's package
recently. I have had just one problem, which I think I can fix, bit I would
like to see if others agree with my solution.

The problem seems to arise when the system decides to wait and retry after
getting no response. The debug appeared in the method
SptHTTPRequest>>waitOnReadySpecRetrying:, where the line:
[Delay forSeconds: 5] wait.
produced the message: 'Block Closure does not understand #wait'. It seems to
me that it should be:
(Delay forSeconds: 5) wait.
but if so I am surprised that it has never caused trouble before. Can anyone
see anything wrong with my diagnosis? (By the way, I am still using Dolphin
5.1.4, if that's relevant.)

Thanks

Peter Kenny

Peter,

> It seems to me that it should be:
> (Delay forSeconds: 5) wait.
> but if so I am surprised that it has never caused trouble before.

I think your fix is correct.  I hope it is because it seems that I made exactly
the same change to my copy of Steve's stuff sometime last year, and then forgot
all about it.

It seems to be quite hard to reach the place where this is triggered -- I think
it needs an exceptionally flaky webserver.  I had been using it for at least a
year before I hit the problem.

FWIW, since I'm on the subject, one other change I've made is to
SpHTTPValueProgress>>initialize to read:

========
initialize
    super initialize.
#CUmodified.
    percentageValue := 0 asValue.
    stateValue := ValueHolder new
========

(I can no longer remember why I thought the change necessary or desirable).

My only other change is to SZSockets>>upToCRLF, which in my version reads:

========
upToCRLF
    | stream cr lf |

#CUmodified.
    "it's unwise to assume that servers will actually follow the HTTP spec in
    this, or any other respect.  E.g. thttpd 1 (at least the inept Demon
    installation) seems to use linefeed to terminate header lines.  So we
    arrange to allow any combination of a single lf, a single cr, the cr-lf
    sequence or the lf-cr sequence.  Of course we do *not* allow
    cr-cr or lf-lf"

    stream := self contentsSpecies writeStream: 128.
    cr := Character cr.
    lf := Character lf.

    [self atEnd] whileFalse:
        [| next |
        next := self next.
        next = lf ifTrue: [self peekFor: cr. ^ stream contents].
        next = cr ifTrue: [self peekFor: lf. ^ stream contents].
        stream nextPut: next].

    "we shouldn't reach here, but servers are servers..."
    ^ stream contents.
========

Another small problem I encountered (just during development, it shouldn't
affect most deployed applications) is that the DNS cache it keeps can grow
stale if you use a long-lived image.  There is code to time-out entries, but I
think it can fail if the millisecond clock has wrapped around since that
hostname's ip address was cached.  Anyway, if I'm working with the HTTP Client
in an image, I tend to do:
    SptHTTPHostCache uninitialize.
every day or two.

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:43d669f9$0$87291$[hidden email]...
> Peter,
> I think your fix is correct.  I hope it is because it seems that I made
> exactly
> the same change to my copy of Steve's stuff sometime last year, and then
> forgot
> all about it.

Thanks Chris. I am still unsure of my Smalltalk knowledge, so I just wanted
reassurance.
>
> It seems to be quite hard to reach the place where this is triggered

This happened to me on the first day - perhaps the National Statistics
server was tired on Sunday!

Thanks

Peter

Chris,

> Another small problem I encountered (just during development, it shouldn't
> affect most deployed applications) is that the DNS cache it keeps can grow
> stale if you use a long-lived image.  There is code to time-out entries, but I
> think it can fail if the millisecond clock has wrapped around since that
> hostname's ip address was cached.  Anyway, if I'm working with the HTTP Client
> in an image, I tend to do:
>     SptHTTPHostCache uninitialize.
> every day or two.

Dolphin's delays suffer the same problem, and cannot be fully trusted to
fire after 47.9 days (or is it 49.7??).  If an image makes critical use
of delays, the OS needs to be rebooted that often :(

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> Dolphin's delays suffer the same problem, and cannot be fully trusted to
> fire after 47.9 days (or is it 49.7??).  If an image makes critical use
> of delays, the OS needs to be rebooted that often :(

Fortunately, the workaround for HTTP Client is simpler than that ;-)

I mean, come on, even IE doesn't need a system reboot just to download a file !

Well, not usually...

    -- chris