Bug 29166 - Expect: 100-Continue fails after 401 Unauthorized
Summary: Expect: 100-Continue fails after 401 Unauthorized
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Connector:HTTP (show other bugs)
Version: 5.0.16
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-24 07:00 UTC by Chris Floersch
Modified: 2005-03-20 17:06 UTC (History)
0 users



Attachments
Simple test case.. Needs a protected (basic auth) servlet (3.02 KB, application/octet-stream)
2004-05-24 07:13 UTC, Chris Floersch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Floersch 2004-05-24 07:00:08 UTC
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.
Comment 1 Chris Floersch 2004-05-24 07:13:07 UTC
Created attachment 11638 [details]
Simple test case.. Needs a protected (basic auth) servlet
Comment 2 Remy Maucherat 2004-05-24 21:32:29 UTC
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.
Comment 3 Remy Maucherat 2004-05-31 10:59:14 UTC
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.