Re: Authentication behaviour
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication behaviour
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication behaviour
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication behaviour
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Authentication behaviour
On 30 Sep 2008 at 18:27, Caldarale, Charles R wrote: From: Maurizio Lotauro [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Authentication behaviour
From: Maurizio Lotauro [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
