tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maurizio Lotauro" <maurizio.lota...@territoriumonline.com>
Subject Re: Authentication behaviour
Date Wed, 08 Oct 2008 23:09:24 GMT
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


Mime
View raw message