On Sat, 31 Dec 2011, karim khalid wrote:

> I am sorry but I am newer here

I am aware of that. That's an even bigger reason for you to read our
netiquette guidelines before you post. You won't get more friends here by
ignoring them.

> Really I don't belive that the latest version of WebLogic and Jboss (tomcat)
> doesn't handlets correctly this header Http, they are compliant with W3C
> recommandation.

How can you be so sure they are? I don't want to be rude, but it sounds as if
you don't quite understand the HTTP Expect: header and you come questioning
our take on it and assume that some others do it right while we are not.

Server-side Expect: header handling might be one of the most commonly broken
things in HTTP land in general.

> Could you please explain how curl handles this header Http ?

curl sends the Expect header and expects the server to respond with a
100-continue as RFC2616 says (or an error in case there's a problem with the
request/auth/whatever). If it doesn't respond within a short time (1000 ms to
be exact), curl will assume the server won't deal with Expect: and goes on and
it sends the request anyway. (This is incidently how the HTTP 1.1 spec
suggests a client should behave even though it doesn't specify the time-out.)

> if you could send me the codeline that implements this header in version
> 7.15.5 and the latest version

Sorry, but digging around in the ancient 7.15.5 code base is left for you to
do if you feel you really must (although I think the logic was quite similar
already back then). In current curl code the 100-continue logic is mostly
found in lib/transfer.c and you can search for CURL_TIMEOUT_EXPECT_100 and
exp100 to see it. It isn't really made in one single spot, as it is a
timeout-based thing.

> I don't want to switch to the latest version( our code :200000 lines) before
> to be sure that is a bug in this version 7.15.5

I don't think this is a bug in 7.15 and I don't think this is a bug in the
current code either. We have a whole range of test cases that use it and
verify it.

I'm not ruling out a bug somewhere in this, but I need more details first that
would indicate this before I'll bark up that tree.

> Response:
>
> < HTTP/1.1 100 Continue
> * Operation timed out after 30 seconds with 0 bytes received
> * Closing connection #0

This certainly looks like a broken or very slow server. It responds with a 100
Continue and then it doesn't do anything else within 30 seconds. The 30
seconds time-out is probably a limit your app has set? Perhaps you should
allow it more time?

If the server responds fine if you omit the Expect: header I consider it a
good indication that the bug might be in the server end.

It is quite easy for you to just remove the Expect: header from curl's request
and be fine with that.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html