Re: Yet More Expect-Continue

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Yet More Expect-Continue

Schopp, James (Jimi)
What is the current status of expect/continue patch?
 
I have encountered the following problem (related to this) and I have a patch as well (no diff, but just 3 lines), that at least works in my situation.
 
The Scenario is:
I am performing a Web Services call (from a .Net client) to Axis running Jetty, using BASIC AUTH over HTTPS.
 
1) On the initial request, .Net does NOT send the WWW-Authentication header, but does send an Expect: 100 -Continue.
2) Jetty reads the headers (but NOT the body), and determines that we are not authenticated to make the request. Jetty returns a 401 Unauthorized.
3) The .Net client then sends the same request again as before, but this time with the appropriate WWW-Authentication tag.
4) Jetty begins reading the next request. Since it never cleared the input stream from the first request, it reads that instead, which is garbage. Jetty interprets that garbage as the request "method" ie. POST, or GET, but in this case it's garbage) and returns a 405 Method not allowed.
 
I solved this issue by inserting the following 3 lines of code into HttpConnection.java, at line 627 (method commit() ):
 

// Check if there is missing content expectations

if (_inputStream.getExpectContinues()!=null)

{

                     // No input read yet - so assume it never will be                    

                     _inputStream.setExpectContinues(null);

                     //BEGIN PATCH NEW ADDITION JAMES SCHOPP

                     for (int i=_inputStream.getContentLength(); i>=0;i--) {

                     _inputStream.read();

                     }

                     //END PATCH NEW ADDITION JAMES SCHOPP

                     _inputStream.unsafeSetContentLength(0);

}

 

So, the idea here is, just eat up the extra bytes on the input stream before leaving so that we are correctly positioned for the next request. NOTE that "skip" did not work here, so I had to read single bytes in a loop. I'm sure with more investigation it could work, but I had enough just figuring out what this error was.

thanks, jimi