[foaf-protocols] Webid Spec: HTTP status codes?

Joe Presbrey presbrey at mit.edu
Fri Aug 13 21:33:42 CEST 2010


On Fri, Aug 13, 2010 at 10:21 AM, Bruno Harbulot
<Bruno.Harbulot at manchester.ac.uk> wrote:
> What I was suggesting is to complement that (perhaps using some
> re-negotiation) with suitable information at the HTTP layer (so a
> non-trusted certificate wouldn't be accepted, but simply ignored rather
> than terminating the TLS connection).

I agree. This should be described as a Best Practice.

> This is of course not a trivial thing to do, since it would require some
> work on both sides (client and server).

We can already do this with modifications to mainstream servers and
modules, Apache/mod_ssl, and have demos.  Or I didn't understand what
you were describing (sorry).

> Well, HTTP has always treated 'authentication' and 'authorization' quite
> ambiguously. In most cases, 'unauthorized' actually means
> 'unauthenticated and therefore unauthorized'.
>
> The problem with 401 is in the 'MUST'
> <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2>:
>    "The response MUST include a WWW-Authenticate header field (section
> 14.47) containing a challenge applicable to the requested resource."

Indeed on both counts. For responsible use of 401 in mod_authn_webid,
I must reinterpret this text, like I do other old commandments, from
within my own post-modern context:
"The response MUST include a [HTTP-standards-based] field containing a
challenge applicable to the requested resource."

Of course for WebID, the "challenge" is the SSL client certificate request.

In general, 401 is for not authenticated and 403 is for not authorized
(or both).  AFAIK, this spec should be dealing primary with
authentication => 401 unless we want to come up with some higher 40x's
to supersede my current 'specify the specific authentication error in
the response body' plan.

--
Joe Presbrey


More information about the foaf-protocols mailing list