"H. Chaudet" wrote:
>
> >>
> >> - Time response to http fetching shows important fluctuations:
> >> Just build a simple browser that just set the htmltext of a fld with the
> >> content of an url given in another fld and then make a call to "answer OK".
> >> Then try to display the content of the two urls
> >> "http://wilson.ai.mit.edu/cl-http/cl-http.html"; and
> >> "http://wilson.ai.mit.edu/cl-http/headers.html";
> >> With MC 2.3 the response is (quasi) immediate.
> >> With MC 2.4, in the second case, the script is hung for some seconds.
> >
> >I just tested the urls with the most recent libURL. The first url loads
> >fine as you say but the second one shows a problem more with the server
> >then the stack. It is what they call a dynamically-produced content
> >which means that the page header doesn't provide the total length of the
> >message but the message is divided into "chunks" and you get the next
> >chunk size as you go along the last one being of course "0".
> >I would say that the library handles this correctly since I tested with
> >as many urls I could find and it is the server which either doesn't
> >count the chunk length properly or it forgets to add a crlf after each
> >chunk as it is supposed to. Note that the server (common Lisp-http) is
> >not a standard one and it may be not sufficiently tested.
> >I will look into this some more though.
> >
>
> At a first glance on the scripts in libURL, I've found something that
> corrects the problem. In the script "andmore", the case of a chunked
> transmission seems to be recursively treated until the chunk size is "O"
> (is it correct ?). In this last case, the first instruction is a read from
> socket. I've commented this instruction, thinking that if a chunk as no
> size, it does not exist and it is not necessary to read it.
Correct, that read makes no sense, I don't know how it got in there;-).
Trouble is, in the meantime I changed the way the reading is done from
"read for x with message..." to "read with message..." allowing for a
more continuos non blocking flow and verifying the chunk lengths on the
fly. This last part is tricky since I am blindly counting on all the
pieces being there.
I can send you the stack off the list if you want to play with it.
> The result appears to work without problem.
> Is there any possible problem with this modification?
>
> Herve
>
Andu
Archives: http://www.mail-archive.com/[email protected]/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
