Re: Expect: 100-continue

[Remy Maucherat]

Julian Reschke wrote:
Hi,
Looking at :
--
DESCRIPTION OF THE PROBLEM :
The servlet API provides no means of controlling the 100- continue 
response when the user agent expects it, and doesn't specify when it is 
or is not sent by the servlet container. It should do so.  One 
suggestion to handle this would be:

1. Add a method to HttpServletRequest called acceptRequest or some such, 
which causes a 100-continue to be sent. acceptRequest would have no 
effect if the user agent doesn't expect a 100-continue.

2. Specify that 100-continue will not be sent until one of the following 
happens to the request object:

   a. acceptRequest() is called
   b. getInputStream() or getReader() is called
   c. For the POST method, getParameter() or similar is called.
This would be compatible with the current specification (though not with 
current tomcat, which always sends 100- continue immediately), but 
provide the ability for better control.
--

Does Tomcat5 (or 4, for that matter) actually implement one of these 
options (2b&c, for instance)?
Tomcat always automatically sends a 100-continue when going into the 
filter pipeline if an expectation is requested.

This should be on tomcat-user, BTW.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Expect: 100-continue

[Julian Reschke]

Hi,
Looking at :
--
DESCRIPTION OF THE PROBLEM :
The servlet API provides no means of controlling the 100- continue 
response when the user agent expects it, and doesn't specify when it is 
or is not sent by the servlet container. It should do so.  One 
suggestion to handle this would be:

1. Add a method to HttpServletRequest called acceptRequest or some such, 
which causes a 100-continue to be sent. acceptRequest would have no 
effect if the user agent doesn't expect a 100-continue.

2. Specify that 100-continue will not be sent until one of the following 
happens to the request object:

   a. acceptRequest() is called
   b. getInputStream() or getReader() is called
   c. For the POST method, getParameter() or similar is called.
This would be compatible with the current specification (though not with 
current tomcat, which always sends 100- continue immediately), but 
provide the ability for better control.
--

Does Tomcat5 (or 4, for that matter) actually implement one of these 
options (2b&c, for instance)?

Best regards, Julian
--
bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 29166] - Expect: 100-Continue fails after 401 Unauthorized

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29166>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29166

Expect: 100-Continue fails after 401 Unauthorized

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 29166] - Expect: 100-Continue fails after 401 Unauthorized

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29166>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29166

Expect: 100-Continue fails after 401 Unauthorized





--- Additional Comments From [EMAIL PROTECTED]  2004-05-31 10:59 ---
Ok, I've looked at this. Your test case is not particularly helpful: a simple
telnet is a lot better.
The purpose of 100 is to avoid transferring the (large) request content.
Keepalive in that case is a very small bonus, and Tomcat doesn't handle this yet.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 29166] - Expect: 100-Continue fails after 401 Unauthorized

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29166>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29166

Expect: 100-Continue fails after 401 Unauthorized





--- Additional Comments From [EMAIL PROTECTED]  2004-05-24 21:32 ---
100s are optional anyway. BTW, putting comments which look like science fiction
doesn't help the credibility of your bug report.
I also think the code which handles 100s to be obvious enough. I recommend you
look into this further.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 29166] - Expect: 100-Continue fails after 401 Unauthorized

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29166>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29166

Expect: 100-Continue fails after 401 Unauthorized





--- Additional Comments From [EMAIL PROTECTED]  2004-05-24 07:13 ---
Created an attachment (id=11638)
Simple test case.. Needs a protected (basic auth) servlet

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 29166] New: - Expect: 100-Continue fails after 401 Unauthorized

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29166>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29166

Expect: 100-Continue fails after 401 Unauthorized

   Summary: Expect: 100-Continue fails after 401 Unauthorized
   Product: Tomcat 5
   Version: 5.0.16
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:HTTP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A POST to a protected servlet using Expect: 100-continue results in a 401 
Unauthorized return. If that same connection is held open and the POST is 
resubmitted again using the Expect: 100-continue along with appropriate 
Authorization credentials the 100 Continue is never sent. Timing out on waiting 
for the 100 Continue and sending the entity body anyways results in a 505 HTTP 
Version Not Supported.

In the following senario I am not using a front end web server nor the jk2 
connector. I am using tomcat 5.0.16 with a basic HTTP Connector running as a 
service on Windows2000 with the latest service packs. There are no reported 
errors in the logs.

java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)


** REQUEST **
POST /client/servlet/EchoExample HTTP/1.1
Host: localhost:8000
User-Agent: NetLib/1.0
Accept: text/html, text/xml, text/plain, image/gif, image/png, image/jpeg, */*
Accept-Language: en-us
Accept-Charset: ISO-8859-1;q=0.8, UTF-8;q=0.6, *;q=0.3
Content-Type: multipart/form-data; 
boundary="=_Part_0_27379847.1085374393407"
Content-Length: 727
TE: gzip;q=0.8, deflate;q=0.2
Expect: 100-continue
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

** RESPONSE **
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Realm 1"
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-US
Content-Length: 911
Date: Mon, 24 May 2004 04:53:18 GMT
Server: Apache-Coyote/1.1

bunch of stuff here.


** RE REQUEST **
POST /client/servlet/EchoExample HTTP/1.1
Host: localhost:8000
User-Agent: NetLib/1.0
Accept: text/html, text/xml, text/plain, image/gif, image/png, image/jpeg, */*
Accept-Language: en-us
Accept-Charset: ISO-8859-1;q=0.8, UTF-8;q=0.6, *;q=0.3
Authorization: Basic dG9tY2F0MTp0b21jYXQ=
Content-Type: multipart/form-data; 
boundary="=_Part_0_27379847.1085374393407"
Content-Length: 727
TE: gzip;q=0.8, deflate;q=0.2
Expect: 100-continue
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache


<= THIS IS WHERE THE 100 Continue is never sent and my client code timeouts =>
<= I attempt to send entity body anyway assuming HTTP/1.0 client as per RFC =>

** FINAL RESULT **
HTTP/1.1 505 HTTP Version Not Supported
Date: Mon, 24 May 2004 04:53:25 GMT
Server: Apache-Coyote/1.1
Connection: close



The work around on the client is to close the connection and get a new 
connection before retrying. Obviously this defeats the point of using the 
Expect: 100-continue in the first place.

It seems that the same senario without the intermediary 401 Unauthorized works 
without issue.

After some testing I have found that as long as the Content-Length < 5 it seems 
to work properly. But if the Content-Length >= 5 it never returns 100 Continue.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]