> Date: Thu, 13 Dec 2007 21:40:52 +0100 (CET)
> From: Daniel Stenberg <daniel_at_haxx.se>
> On Thu, 13 Dec 2007, Jean Marie COUPRIE wrote:
>
>> Please add in the Man page of Curl (in big characters) a warning saying that
>> if the application send several messages to answer 1 Curl request, Curl see
>> (and give to the user) only the first one that may be very different from
>> what a browser see.
>
> I don't see how that makes any sense. curl fetches the response from the
> server. A single request gets a single response. I think you're confusing
> matters, but I can't exactly figure out how.
>
> Can you please elaborate?

Apparently "A single request gets a single response." is false if the
server use a welcome message : After successful log on, the server send
a message screen that say approximatively " Welcome userid, you have
been connected, you will be redirected in a few seconds. If you are not,
click here" then it send the first application screen. Curl reports only
the welcome message, the user of a browser sees both.

There are 2 methods to use an application on a server :
1) Manually with a browser (e.g. FireFox) I see a sequence of screens (I
can record in a file their source code). When I click on an URL (a link)
this generate a dozen of get according to liveHTTPHeaders because the
browser execute the html or java code sent by the server.
2) With a program using curl, it send only 1 get by curlperform
(normally to obtain a screen content) and put the source code in a file
without executing it.
The user assumes that the contents of files in 1) and 2) are similar.
This may be completely wrong : in the present example of log on 2) gives
70 octets and 1) gives 20 ko. ... I wish that the man page warn against
this false assumption and emphasize this difference of behavior.
>
>> Is it possible to give to the user all the messages received before a
>> time-out with separators between them ?
>
> I believe you're talking about HTTP here? HTTP 1.1 works as defined by
> RFC2616, and curl does its best to adhere to that. Can you please point out
> what parts you claim it fails to follow?
Yes I am talking about HTTP.
See above the welcome message problem, I have not seen it described in
RFC2616, it is probably the application that send the second message and
not a question of protocol.
>
>> An other problem that I have found, but it may be particular to the Rexx
>> port that I use, Curl keep the information that it has to post and post in
>> the requests following the normal post request.
>
> Now you're talking libcurl here, right? An easy handle in libcurl keeps all
> the set options until you change them. That means that if you set data to
> POST, that data will be sent with the handle on all future requests done with
> that handle unless you change the option in between the requests. This is
> documented and should not be a suprise.
>
> Or did I misunderstand?
>
> (and libcurl stuff is better taken to the curl-library mailing list...)
What is your advice ? Copy this in a post to curl-library mailing list ?
>
>> I had to reset the post option. Is this a bug to report to the author of the
>> Rexx port ?
>
> The Rexx binding most probably works like that since libcurl itself works like
> that.
>
I have found in the RexxCurl manual "CURLSETOPT(handle, option,option
value[,more option values,...])
This function is called to define all the parameters and data required
to carry out the particular request." So I have assumed that the
parameters were valid only for the present (particular) request and that
they disappeared before the next request... And I have written a routine
that reenters each time the common options. It seem that it is not
needed but does not cause problem. Easy-curl text is not ambiguous.
Where can I find a list of default options ? It is not obvious in the
easy-curl list of man pages...
Received on 2007-12-14