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