Re: [File API] Dereferencing Model for Blob URIs

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*
>
>

Received on Thursday, 13 October 2011 20:32:39 UTC