Marek Potociar wrote
>
> From the HTTP 1.1 specification:
>
> If the client has performed a conditional GET request and access is
> allowed, but the document has not been modified, the
> server SHOULD respond with this status code. The 304 response MUST NOT
> contain a message-body, and thus is always
> terminated by the first empty line after the header fields.
>
Hi Marek,
It's not clear what should happen if a user tries using a HTTP 304 in
response to a PUT.
1) Should notModified() fail at runtime?
2) Should notModified() succeed, but entity() throw an exception?
3) Should the user be allowed to include a body for a PUT?
Forgetting notModified() for a second, what HTTP response should I send back
to the user?
The user is attempting a PUT that consumes a URL that the user cannot
evaluate. Upon further investigation, the server discovers that the
referenced resource is "no good" (See [1] for more information). What
response should the server return?
I don't think 400 BAD REQUEST is appropriate because the request is
well-formed and the user has no way of knowing ahead of time that it will
fail.
The closest match I could find was 403 FORBIDDEN but even that seems like a
poor match. Any ideas?
[1] The client PUTs a URL referencing to a VGA Monitor. The server attempts
to read the DDC value of the monitor (over the VGA cable). If the monitor
does not support DDC (cheaper monitors do not) then the PUT operation cannot
be honored. The client has no way of checking for DDC support ahead of time.
Gili
--
View this message in context: http://jersey.576304.n2.nabble.com/HTTP-304-is-silently-dropping-the-entity-tp7032018p7032501.html
Sent from the Jersey mailing list archive at Nabble.com.