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

[Bruno Harbulot]

Hi,

On 12/08/2010 21:05, Akbar Hossain wrote:
> Hi,
>
> 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.
>
> http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
>
> 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 
of things.
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.

http://www.ietf.org/mail-archive/web/tls/current/msg05589.html


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.


Best wishes,

Bruno.