Hi Tobias,401 is unauthorized (not allowed to do something), but anonymous is used when nobody is authenticated (the application does not know who is talking). Without being authenticated, you cannot make any statements about authorization - and this is the problem with sending a 401 as first response.
And using form-based authentication is by no means a better solution. HTTP has built-in means of authentication and we should use them, so that standard HTTP clients can work with our applications. And this means allowing HTTP Basic or HTTP Digest, using proper challenge- response, so that no preemptive authentication is necessary and so on.
Using form-based authentication can and should be implemented using a servlet filter that catches 401 responses and renders an HTML form or using a client-side script that uses AJAX for logging in using a styled form and HTTP Basic.
On 28.02.2008, at 17:00, Tobias Bocanegra wrote:
If all you send is a 403, the user has no means of logging in.Browsers only display the login box if a 401 response has been received.well, 401 is unauthorized - but the anonymous is authorized. thus a 403 forbidden should be sent, since the user is forbidden to write content. we should avoid using the default basic auth and use form-based auth instead. this way you can send along your auth cookie and everything works.If a user is properly logged in and his privileges do not allow toaccess a potion of content, 403 is the right response. But in the caseof the anonymous user that has been logged in by default without ever giving the user the possibility to log-on, 401 would be the correct response.i think it's the job of the client to ensure this.
You might think so, but in fact, browsers do not send any credentials if they have not been asked for them. And a 401 response is the HTTP way of saying "please tell me who you are", so we should send this response. If your client is a HTTP client programming library you can (in some libraries, not in all) configure it to send preemtive- authentication data, but this is a completely different topic.
regards, Lars -- Lars Trieloff [EMAIL PROTECTED] http://weblogs.goshaky.com/weblogs/lars
smime.p7s
Description: S/MIME cryptographic signature
