On 8/31/11 3:49 AM, Anne van Kesteren wrote:
This model should be rephrased a bit to make it more clear what the
requirements are. E.g. I think if you use POST it should not be a MAY
but a MUST that 500 is returned.
Also what are the security errors you can get a 500 for? Are they not
handled by 403? I think handling them with 403 is counter to how they
are handled elsewhere though. Usually any kind of error is handled as
a generic network error. I think it might be better to simply use 200
if the method was GET and 500 for everything else. You should probably
also state what needs to happen with user/password arguments and maybe
add a note that request headers are ignored. Furthermore, it has a
note of sorts that you can expect a Content-Type header in the
response, but it should be more detailed about what
getAllResponseHeaders() will return. I.e. give a more complete
definition of the response.
1. I've made it clearer what all the request and response headers should be.
2. I've simplified the model to only include 200 and 500 responses; in
particular, I was swayed by the argument not to leak information, and
felt that a minimum number of response codes would be most useful.
3. An open question is what ought to be done about user/password
arguments. Servers honor them, but I'm not entirely certain browsers on
top of file systems need to do anything here. I sense there's a use
case here, but if there is, it hasn't been articulated. For now, the
protocol doesn't really allow or disallow them. What is your opinion
for what should be done?
-- A*
