-----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]
