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]

Reply via email to