W3C home > Mailing lists > Public > www-lib@w3.org > July to September 1999

POST works with HTSSL (was RE: Bug in libwww-ssl -- can I fix?)

From: Gordon Prioreschi <gpriores@ix.netcom.com>
Date: Mon, 20 Sep 1999 16:08:09 -0700
Message-Id: <Version.32.19990920145815.0107b890@popd.ix.netcom.com>
To: www-lib@w3.org
Olga writes:
>On 17-Sep-99 Gordon Prioreschi wrote:
>> At 10:12 AM 9/17/99 -0500, Olga Antropova wrote:
>>>So you are trying to use ssl with library's POST (that means with
nonblocking
>>>sockets and event loops!). Could you please let me know if it works - I
have
>>>never tried that.

After much tracing through libwww, HTSSL, openSSL, and HTTCP code, it turns
out initializing HTSSL with preemptive=NO seemed to do the trick.

I can't say that necessarily it works in all cases, but it does seem to
work for POSTing the login form of the particular server to which I'm
trying to connect.

>> The primary problem I'm tracking might have something to do with this. I
>> believe that libwww sends the MIME header, the server it's connected to
>> sends back a "continue", at which point libwww does a read for some reason
>> instead of sending the body of the POST.

>I do not know if it will help but try to set BodyWriteDelay to shorter then
>default time

The thing was ignoring the BodyWriteDelay timer completely when preemptive
was set to YES (the socket was not set to O_NONBLOCK). Not sure if playing
around with the preemptive flag in other places (such as the HTTP protocol)
would have given me a solution for preemptive = YES, as I haven't
completely figured out the semantics of the preemptive flag and I stopped
looking at it once I got my code to work.

(Bailing like that is kinda lame, I know, but I'm really just trying to
hack together a quick utility for the periodic automated retrieval of a
specific piece of information, and I've already spent waaaay more time on
it than it's worth...)


In the course of figuring this out, I did pull RFC 2616 to look up the
"continue" thing. Apparently, servers are allowed to send a continue in
response to HTTP/1.1 PUT or POST requests even when one is not Expected, as
some clients are able to send a request body immediately on receipt of a
continue even though they do not specify the Expect field.

A minor optimization for the ToDo list? (The client *should* specify the
Expect, presumably...)


Anyway, once I've finished the utility I'm working on, I'll hopefully have
a little slack time to go back and patch the bug I previously reported.


                                        Later,

                                            -g
Received on Monday, 20 September 1999 19:09:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:17 UTC