[ jetty-Bugs-1290408 ] Input stream incorrectly positioned on persistent connection

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[ jetty-Bugs-1290408 ] Input stream incorrectly positioned on persistent connection

SourceForge.net
Bugs item #1290408, was opened at 2005-09-13 19:53
Message generated for change (Comment added) made by gregwilkins
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107322&aid=1290408&group_id=7322

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP protocol
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jimi Schopp (jamesschopp)
>Assigned to: Greg Wilkins (gregwilkins)
Summary: Input stream incorrectly positioned on persistent connection

Initial Comment:
I have encountered a scenario where the
HttpConnection's inputStream "current pointer" is badly
positioned, making future requests appear corrupted.

The Scenario is:
I am performing a Web Services call (from a .Net client)
to Jetty 5.1.5rc1 (containing an ApacheAxis-based web-
app), 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. So, Jetty returns a 401 Unauthorized.
3) The .Net client realizes it needs to authenticate, so it
then sends the same request again as before, but this
time with the appropriate WWW-Authentication tag.
4) Jetty begins reading the next request. BUT, since it
never cleared the input stream from the first request,
and we are on the same socket connection, instead of
reading the request headers, it instead reads remaining
body of the previous request. Oddly, Jetty interprets
data as the request "method" (ie. POST, or GET, but in
this case it's garbage), since that's the first thing it
expects in an HTTP request, 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() ). I have also included my modified version of
the source file, so you can diff if necessary (source is
based on Jetty 5.1.5rc1).
 
// 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

 


----------------------------------------------------------------------

>Comment By: Greg Wilkins (gregwilkins)
Date: 2005-09-16 22:40

Message:
Logged In: YES
user_id=44062

This actually sounds like a bug in .NET.
If their client sends an Expect: 100-Continue header,
then they should not send any request body unless
the server responds with a 100-continue.

Because Jetty does not read the body, it should not
send a 100 continues and the .NET client should not
send the request body.    This is RFC2616.

I better temp fix would be to modify the Authenticator to
read the content before sending the 401 - this would force
a 100-continue to be sent.  Changing the HttpConnection
is more likely to break something else (eg a good client
that actually does not send the body).

Does this happen if you are not using HTTPS?
If so, could you capture an ethereal packet dump of the
conversation.  This will allow us to verify the problem is with
.Net and you can raise a bug against them.  We can then also
better consider a good work around  - which may involve
triggering on the agent header.

If it only happens with https, can you turn full debugging
on and send me the log file.

thanks




----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107322&aid=1290408&group_id=7322


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Comment: [ jetty-Bugs-1290408 ] Input stream incorrectly positioned on persistent connection

Tony Seebregts
Hi James,

Just run my suite of Expect-Continue tests both with and without
pre-emptive basic authorization and they run just fine and the wire log
show the expected behaviour..

I'm using HttpClient though so Greg may be right that its something to
do with the .NET implementation.

regards

Tony Seebregts


SourceForge.net wrote:

>Bugs item #1290408, was opened at 2005-09-13 19:53
>Message generated for change (Comment added) made by gregwilkins
>You can respond by visiting:
>https://sourceforge.net/tracker/?func=detail&atid=107322&aid=1290408&group_id=7322
>
>Please note that this message will contain a full copy of the comment thread,
>including the initial issue submission, for this request,
>not just the latest update.
>Category: HTTP protocol
>Group: None
>Status: Open
>Resolution: None
>Priority: 5
>Submitted By: Jimi Schopp (jamesschopp)
>  
>
>>Assigned to: Greg Wilkins (gregwilkins)
>>    
>>
>Summary: Input stream incorrectly positioned on persistent connection
>
>Initial Comment:
>I have encountered a scenario where the
>HttpConnection's inputStream "current pointer" is badly
>positioned, making future requests appear corrupted.
>
>The Scenario is:
>I am performing a Web Services call (from a .Net client)
>to Jetty 5.1.5rc1 (containing an ApacheAxis-based web-
>app), 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. So, Jetty returns a 401 Unauthorized.
>3) The .Net client realizes it needs to authenticate, so it
>then sends the same request again as before, but this
>time with the appropriate WWW-Authentication tag.
>4) Jetty begins reading the next request. BUT, since it
>never cleared the input stream from the first request,
>and we are on the same socket connection, instead of
>reading the request headers, it instead reads remaining
>body of the previous request. Oddly, Jetty interprets
>data as the request "method" (ie. POST, or GET, but in
>this case it's garbage), since that's the first thing it
>expects in an HTTP request, 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() ). I have also included my modified version of
>the source file, so you can diff if necessary (source is
>based on Jetty 5.1.5rc1).
>
>// 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
>
>
>
>
>----------------------------------------------------------------------
>
>  
>
>>Comment By: Greg Wilkins (gregwilkins)
>>    
>>
>Date: 2005-09-16 22:40
>
>Message:
>Logged In: YES
>user_id=44062
>
>This actually sounds like a bug in .NET.
>If their client sends an Expect: 100-Continue header,
>then they should not send any request body unless
>the server responds with a 100-continue.
>
>Because Jetty does not read the body, it should not
>send a 100 continues and the .NET client should not
>send the request body.    This is RFC2616.
>
>I better temp fix would be to modify the Authenticator to
>read the content before sending the 401 - this would force
>a 100-continue to be sent.  Changing the HttpConnection
>is more likely to break something else (eg a good client
>that actually does not send the body).
>
>Does this happen if you are not using HTTPS?
>If so, could you capture an ethereal packet dump of the
>conversation.  This will allow us to verify the problem is with
>.Net and you can raise a bug against them.  We can then also
>better consider a good work around  - which may involve
>triggering on the agent header.
>
>If it only happens with https, can you turn full debugging
>on and send me the log file.
>
>thanks
>
>
>
>
>----------------------------------------------------------------------
>
>You can respond by visiting:
>https://sourceforge.net/tracker/?func=detail&atid=107322&aid=1290408&group_id=7322
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. Download
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>jetty-discuss mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>
>
>  
>



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss