hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Athentication/Expect-Continue - Follow-Up
Date Wed, 22 Jun 2005 08:13:35 GMT
Tony,

Here's my take for what it is worth

Section 8.2.3 of RFC2616 "Use of the 100 (Continue) Status" clearly
states the following:

...
 The purpose of the 100 (Continue) status (see section 10.1.1) is to
 allow a client that is sending a request message with a request body
 to determine if the origin server is willing to accept the request
 (based on the request headers) before the client sends the request
 body. In some cases, it might either be inappropriate or highly
 inefficient for the client to send the body if the server will reject
 the message without looking at the body. 
...
 
While not entirely restricted to enforcing security constraints, as
correctly asserted by Jetty's developers, in my opinion the chief reason
for the origin server not "willing to accept the request (based on the
request headers)" is (1) violation of the request format, (2) invalid
authentication or (3) insufficient access permissions on the part of the
client
 
The interpretation of the 100-continue handshake by the Jetty's
developers while not directly contradictory to the formal letter of the
HTTP spec, IMHO fails to adequately address the fact that in many
real-life scenarios HTTP requests are rejected solely based on security
considerations

RFC 2617
1.2 Access Authentication Framework
...
 If the origin server does not wish to accept the credentials sent
 with a request, it SHOULD return a 401 (Unauthorized) response. The
 response MUST include a WWW-Authenticate header field containing at
 least one (possibly new) challenge applicable to the requested
 resource. If a proxy does not accept the credentials sent with a
 request, it SHOULD return a 407 (Proxy Authentication Required). The
 response MUST include a Proxy-Authenticate header field containing a
 (possibly new) challenge applicable to the proxy for the requested
 resource.
...

Overall, Jetty's implementation of the 100-continue handshake in its
present form simply makes Jetty less useful. Plain and simple. It us up
to Jetty's folks to choose either to ignore this fact or deal with the
issue

Oleg
  
  Wed, Jun 22, 2005 at 09:09:46AM +0200, Tony Seebregts wrote:
> Hi Oleg/Roland,
> 
> FYI, I've posted the reply from the Jetty support list about the
> Authentication/Expect-Continue problem (from about a week back). Seems like
> its an area open to interpretation.
> 
> > | In Jetty at least the connection is not made between the application 
> > | security constraints and the need to send (or not) a 100-continue.
> >
> > Per the specification, a 100-continue response is an:
> >
> > ".../interim response/ [which] is used to inform the client that the
> > /initial part of the request/ has been received and *has /not yet/ 
> > been rejected by the server*." -- HTTP 1.1 Spec., '10.1.1. 100 Continue'
> > 
> > Obviously, a 100-continue response does not indicate that the final 
> > request will not be rejected but only that the request in its initial 
> > state is "so far OK".  This has absolutely nothing to do with whether the 
> > URI itself requires authentication for the /final request/.  
> >
> > "....The server MUST send a /final response/ /after the request has been 
> > completed/." -- supra. 
> > Note that the specification states only that a "final response" is to be 
> > sent after the full request is sent.  It says nothing about whether any 
> > other interim responses can be sent along with the 100 response, nor does 
> > it indicate that a 100 response must be sent alone.
> 
> Would be interested to hear your comments/interpretation. The Jetty
> developers are posting it to the RFC EG for clarification in the meantime
> though.
> 
> Regards
> 
> Tony Seebregts
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


Mime
View raw message