You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Tony Seebregts <to...@cibecs.com> on 2005/06/22 09:09:46 UTC
Athentication/Expect-Continue - Follow-Up
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
Re: Athentication/Expect-Continue - Follow-Up
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
RE: Athentication/Expect-Continue - Follow-Up
Posted by Tony Seebregts <to...@cibecs.com>.
Hi Oleg/Roland,
Thanks very much for the comments - was reassured to see my thoughts were
pretty much in line with yours. I'll let you know what comes out of the RFC
discussion.
Regards
Tony
-----Original Message-----
From: Roland Weber [mailto:ROLWEBER@de.ibm.com]
Sent: 22 June 2005 10:28
To: HttpClient User Discussion
Subject: Re: Athentication/Expect-Continue - Follow-Up
Hello Tony,
thanks for keeping us up to date. My comment is the same as before:
technically, the spec is implemented correctly, but the purpose of
the 100-continue handshake is not achieved.
RFC 2616 [HTTP/1.1], section 8.2.3:
> 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.
So if the authentication requirement does not depend on the contents
of the request body, the server SHOULD (but does not have to) send
the "auth required" response instead of a 100-continue. And in most
cases, access control is handled based on the URI, which is part of
the message header.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Athentication/Expect-Continue - Follow-Up
Posted by Roland Weber <RO...@de.ibm.com>.
Hello Tony,
thanks for keeping us up to date. My comment is the same as before:
technically, the spec is implemented correctly, but the purpose of
the 100-continue handshake is not achieved.
RFC 2616 [HTTP/1.1], section 8.2.3:
> 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.
So if the authentication requirement does not depend on the contents
of the request body, the server SHOULD (but does not have to) send
the "auth required" response instead of a 100-continue. And in most
cases, access control is handled based on the URI, which is part of
the message header.
cheers,
Roland
"Tony Seebregts" <to...@cibecs.com>
22.06.2005 09:09
Please respond to
"HttpClient User Discussion"
To
"'HttpClient User Discussion'" <ht...@jakarta.apache.org>
cc
Subject
Athentication/Expect-Continue - Follow-Up
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