You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Maurizio Lotauro <ma...@territoriumonline.com> on 2008/10/01 01:01:22 UTC
Authentication behaviour
Hello,
I'm writing an http client application. When on the server Tomcat is configured to require an
authentication (basic) my client raise a strange error. If authentication is disabled then it
works fine.
I analyzed the communication using WireShark and I noticed a strange behaviour. The
server answers with 401 before it has received the whole content send from client. In fact it
seems that the answer become right after the server has received the http header.
Is this behaviour intentional? If yes, why?
The Tomcat version is 5.5.26
Bye, Maurizio.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authentication behaviour
Posted by Maurizio Lotauro <ma...@territoriumonline.com>.
On 9 Oct 2008 at 14:16, Christopher Schultz wrote:
> Maurizio,
Christopher,
> Maurizio Lotauro wrote:
> > On 6 Oct 2008 at 14:58, Christopher Schultz wrote:
[...]
> If you are writing network code, you need to handle disconnects at
> any time.
This is handled, but in that case there is no need to send the rest of request.
> >> That's a reasonable interpretation of the spec, but obviously
> not
> >> a practical one.
> >
> > Even omitting "and interpreting"?
>
> Sure. The server can interpret part of the request and respond
> whenever
> it wants. Here's another good example: some servers have a
> file-size
> upload limit. If the server were required to process the entire
> file
> upload before rejecting it (based upon the Content-Length header),
> DOS
> attacks would be trivial to mount against any web server.
This is a good point. But I suppose that in this case the server also close the connection,
otherwise it would be useless.
In our case the connection is keep alive.
BTW what is the status code in that case?
[...]
> I think my file upload example is a compelling one.
If the connection is closed by the server then it is a different situation.
Bye, Maurizio.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authentication behaviour
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Maurizio,
Maurizio Lotauro wrote:
> On 6 Oct 2008 at 14:58, Christopher Schultz wrote:
>> Is it a problem to get this 401 before the request is complete?
>
> In my case it was a problem because the receive of the server response trigger an "end of
> operation" state. Then the repeat of the transmission implicitly interrupt the previous one.
> Internally it works asyncronous, and this behaviour breaks its state diagram.
If you are writing network code, you need to handle disconnects at any time.
>> That's a reasonable interpretation of the spec, but obviously not
>> a practical one.
>
> Even omitting "and interpreting"?
Sure. The server can interpret part of the request and respond whenever
it wants. Here's another good example: some servers have a file-size
upload limit. If the server were required to process the entire file
upload before rejecting it (based upon the Content-Length header), DOS
attacks would be trivial to mount against any web server.
> Anyway, as said I my client now is able to handle this situation. The point I wanted only raise
> up was what IMHO doesn't fully adhere to the rfc 2616. Maybe other clients can have the
> same problem.
I think my file upload example is a compelling one. I'm glad you were
able to update your client.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjuSnQACgkQ9CaO5/Lv0PBn5gCgjXyZMYnGtb0sA+Ljmh/cjj6t
m9UAnR0z5us+dQjzSN1Bja8xGX6PGT5s
=ge2Q
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authentication behaviour
Posted by Maurizio Lotauro <ma...@territoriumonline.com>.
On 6 Oct 2008 at 14:58, Christopher Schultz wrote:
> Maurizio,
Christofer,
> Maurizio Lotauro wrote:
> > I already read this rfc and now I have read it again, but I'm
> unable to found where it
> > describe that the server can answer with 401 before the client has
> finished to send all data.
>
> There's nothing that says it can't, either. There's no reason for
> the
> server to wait for all the request data when it knows what it's
> going to return already.
> The HTTP specifications give a lot of latitude to both
> clients and servers.
In general I agree with you. RFC are not always clear or explicit, but I don't think that this is
the case.
> Is it a problem to get this 401 before the request is complete?
In my case it was a problem because the receive of the server response trigger an "end of
operation" state. Then the repeat of the transmission implicitly interrupt the previous one.
Internally it works asyncronous, and this behaviour breaks its state diagram.
> You need to upgrade your client to tolerate this behavior,
> because I'm certain it won't be changed.
I changed the client myself (sources are public available) and now it is able to handle this
behaviour.
> > The rfc 2616, section 6, write: "After receiving and interpreting
> a request message, a server
> > responds with an HTTP response message.".
> > The request message include the message body (see section 5).
> >
> > It seems to me that send the response before receive the whole
> request doesn't follow the
> > rfc.
> > What do you think?
>
> That's a reasonable interpretation of the spec, but obviously not
> a practical one.
Even omitting "and interpreting"?
> What is the problem with the server ignoring this
> additional data?
Nothing. The "problem" is that it don't wait to discard all additional data before sending the
response :-)
Anyway, as said I my client now is able to handle this situation. The point I wanted only raise
up was what IMHO doesn't fully adhere to the rfc 2616. Maybe other clients can have the
same problem.
Bye, Maurizio.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authentication behaviour
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Maurizio,
Maurizio Lotauro wrote:
> I already read this rfc and now I have read it again, but I'm unable to found where it
> describe that the server can answer with 401 before the client has finished to send all data.
There's nothing that says it can't, either. There's no reason for the
server to wait for all the request data when it knows what it's going to
return already. The HTTP specifications give a lot of latitude to both
clients and servers. Is it a problem to get this 401 before the request
is complete? You need to upgrade your client to tolerate this behavior,
because I'm certain it won't be changed.
> In that case the client must anyway send the rest of data before making a new request (or
> close the connection). I don't see any advantage to "early" send the 401 (that was what
> caused the problem to my client).
The advantage is higher performance on the server.
> The rfc 2616, section 6, write: "After receiving and interpreting a request message, a server
> responds with an HTTP response message.".
> The request message include the message body (see section 5).
>
> It seems to me that send the response before receive the whole request doesn't follow the
> rfc.
> What do you think?
That's a reasonable interpretation of the spec, but obviously not a
practical one. What is the problem with the server ignoring this
additional data?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjqX88ACgkQ9CaO5/Lv0PBK7wCff1XrqunzQYWLQUKqyQD3qyoi
tnsAoJqlBx7jrrWz03m2dHVhG5bwwTQ9
=01qb
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Authentication behaviour
Posted by Maurizio Lotauro <ma...@territoriumonline.com>.
On 30 Sep 2008 at 18:27, Caldarale, Charles R wrote:
> > From: Maurizio Lotauro
> > [mailto:maurizio.lotauro@territoriumonline.com]
> > Subject: Authentication behaviour
> >
> > The server answers with 401 before it has received the
> > whole content send from client. In fact it seems that
> > the answer become right after the server has received
> > the http header.
>
> Looks proper to me for basic authentication. As soon as the reference
> to the protected resource is recognized, the 401 is sent; it's up to
> the client to resend all the input with the user credentials on the
> next request.
>
> Read the HTTP Authentication RFC:
> http://tools.ietf.org/html/rfc2617
I already readed this rfc and now I have read it again, but I'm unable to found where it
describe that the server can answer with 401 before the client has finished to send all data.
In that case the client must anyway send the rest of data before making a new request (or
close the connection). I don't see any advantage to "early" send the 401 (that was what
caused the problem to my client).
The rfc 2616, section 6, write: "After receiving and interpreting a request message, a server
responds with an HTTP response message.".
The request message include the message body (see section 5).
It seem's to me that send the response before receive the whole request doesn't follow the
rfc.
What do you think?
[...]
> If you're using form-based authentication, then the server captures
> any POST data submitted with the request, and uses that following
> successful authentication.
No, my is a generic http client and use only the standard http authentication (actually it
supports only basic and ntlm).
Bye, Maurizio.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Authentication behaviour
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Maurizio Lotauro
> [mailto:maurizio.lotauro@territoriumonline.com]
> Subject: Authentication behaviour
>
> The server answers with 401 before it has received the
> whole content send from client. In fact it seems that
> the answer become right after the server has received
> the http header.
Looks proper to me for basic authentication. As soon as the reference to the protected resource is recognized, the 401 is sent; it's up to the client to resend all the input with the user credentials on the next request.
Read the HTTP Authentication RFC:
http://tools.ietf.org/html/rfc2617
For synopses, try these:
http://en.wikipedia.org/wiki/Basic_access_authentication
http://en.wikipedia.org/wiki/Digest_access_authentication
If you're using form-based authentication, then the server captures any POST data submitted with the request, and uses that following successful authentication.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org