Harald Kirsch wrote:
>>> It is not a 400. There was not a technical problem between
>>> machines involved. It is just a user mistake and the machines must and
>>> will deal with this gracefully.
>>>
>> 400 is a *client error* [1]. From the HTTP spec:
>>
>> "The 4xx class of status code is intended for cases in which the
>> client seems to have erred"
>>
>> "10.4.1 400 Bad Request
>>
>> The request could not be understood by the server due to malformed
>> syntax. The client SHOULD NOT repeat the request without
>> modifications."
>
> This is all nice and well, but the *client* mentioned in this spec is a
> piece of software, like a browser that is not properly implemented or
> not properly communicating on the technical level for whatever reason.
The browser is a "user agent" making requests, on behalf of the user,
with information supplied by the user.
I missed some more information:
"10.4 Client Error 4xx
The 4xx class of status code is intended for cases in which the client
seems to have erred. Except when responding to a HEAD request, the
server SHOULD include an entity containing an explanation of the error
situation, and whether it is a temporary or permanent condition. These
status codes are applicable to any request method. User agents SHOULD
display any included entity to the user."
> If the user interface provides functionality to the human in front of
> the machine to upload an XML file and the human errs and uploads a PNG
> image of his grandma, then this is certainly not a 400 (even if tech
> guys like us would call it even worse). It is much the same case as
> entering the zip-code into the street-field of some e-commerce
> application. You are not seriously suggesting to send a 400 in this case.
>
Yes. 400 signifies that the client request is not processable by the
application. It is up to the application to inform the client in a
response why that is. It is up to the "user agent" to render that
response appropriately.
> And of course I don't want to validate the XML on the client side. Maybe
> I should not have called it an 'error' in the subject header, but rather
> a 'user mistake' or whatever?
>
>>> To first send the user to an intermediate page with an error message is
>>> not what user expect today. The resulting page has to have the complete
>>> functionality of where they started plus potentially additional help to
>>> correct their mistake.
>>>
>> The page can still do that by providing links accordingly to what you
>> require.
>
> That would mean to provide nearly identical functionality from two
> different resources.
>
Why?
>>
>>> Say, the main resource is called /map. When uploading some data, this
>>> addresses resource /upload. This resource creates a new resource with
>>> the user's data with some new name, /map/bladfasl, if all goes well and
>>> redirects to /map/bladfasl. But if the data provided by the user is not
>>> all good, the user should
>>>
>>> a) end up on /map again,
>>> b) get an informational message there about what went wrong.
>>>
>>> Obviously just a redirect to /map does not cut it. The /map resource
>>> needs to know somehow that something went wrong.
>
>> Why not allow the client to POST to /map? or allow the client to PUT to
>> /map/{file}? for the former the server is in control of the URI space of
>> the newly created resource, for the latter the client is in control.
>
> Yes, the longer I think about it, it seems that POST to /map is the
> cleanest approach, even if it requires even more functionality on that
> single resource. It would ease the error handling a lot, except that, as
> mentioned above, I don't agree to return a 400. Users will not want to
> see such a technicality. (Have to check, what the browser does with a
> 400. Maybe it surprises me with some magic:-)
>
I bet you have been to pages that say "page not found", if so look at
the status code of the response.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109