[foaf-protocols] Webid Spec: HTTP status codes?
Bruno.Harbulot at manchester.ac.uk
Fri Aug 13 10:49:52 CEST 2010
On 12/08/2010 21:05, Akbar Hossain wrote:
> Wondering if it makes sense to specify/standardise the possible HTTP
> status codes the resource you are trying to access should try to
> respond with.
> Curious how/if TLS errors/failures should be communicated back to the
> identifying agent.
The problem with TLS errors is that they close the connection, so you
don't even get to reach the HTTP layer to provide any HTTP status code.
Some of our implementations let any certificate through and then let the
application at the HTTP layer decide.
In principle, failing to authenticate should return a 401 status code.
Unfortunately, this requires a WWW-Authenticate challenge associated
with the response (there's a MUST in the HTTP spec for this).
There aren't any WWW-Authenticate scheme for telling the user agent that
its transport layer (TLS) should send another certificate or this sort
I've tried to suggest it a while back, but I got mixed answers at the
time. I'm not sure what the interest from browser vendors would be.
In practice, though, it seems that browsers don't mind not having a
WWW-Authenticate challenge when they receive a 401 status code. The
problem is that they don't necessarily know what to do with it.
I think it would be neat to be able to convey a bit more information in
that challenge, for example enough to tell the browser to use another
certificate issuer or to say that it's expecting a WebID certificate.
More information about the foaf-protocols