Redefinition of HTTP: Content-Type on PUT
untitaker opened this issue · 11 comments
If not exactly one Content-Type header was received as part of a
PUT request or the Content-Type header value contains non-ASCII
characters, or it is unreasonably long, the server MAY refuse to
process the request, and instead respond with a descriptive error
message in the body, and a http response code from the 4xx range.
In particular:
or the Content-Type header value contains non-ASCII characters
We're redefining HTTP here again.
https://tools.ietf.org/html/rfc7231#section-3.1.1.5 defines an ABNF for the header value, anything outside of that char range is invalid and obviously triggers a 4xx since it's syntactically invalid
#125 tracks moving this whole paragraph to "best-practices" if I understood correctly, but atm I think it's best to fully remove this paragraph.
We have a special situation because the client, not the server, determines the media-type. Normally, a server should pick a media-type that is listed in the IANA registry, but it would be a lot of work for servers to always check whether a media-type uploaded by a client is in that list. That's why we say servers should accept any ASCII string as the Content-Type value.
I don't think HTTP requires servers to respond with a 4xx to a PUT request if its media-type has not yet been registered through https://tools.ietf.org/html/rfc2048
"any ASCII string as value" includes those which aren't parsable as content-type. Together with requirement that the server returns correct content types, this results in servers being required to echo back invalid values.
If a content-type isn't IANA-registered there are still X- prefixes. I don't see how special semantics are needed here. Am I missing something?
What do you mean by parsable, just the role of '/' and ';'? Should a server refuse to store a resource with a content-type of 'A;C / B'? Maybe, but no implementation I know of is currently doing that.
And should a server refuese to store a resource with a content-type that's parsable, but not in the registry, like 'space/ship; charset=my-own'? I know of no server currently doing that, and the only way to do it would be to ship the list of 800 'allowed' content-type with the server software, and keep it up to date each time someone registers a new content-type.
This may mean you build a server with support for the latest spec, tag it, ship it, announce it, and a day later you need to publish a new version because someone registers a new content-type in the registry and "breaks" your server.
My point is that if you want servers to accept content-types outside of the registry, you should just explicitly say so instead of redefining the whole header.
And should a server refuese to store a resource with a content-type that's parsable
Servers should be allowed to do that, while the current phrasing doesn't mention such a possibility.
All servers should have the same behavior, so you're right, a client can force a server to serve unregistered content-types. I think there's no way around that, but we can mention this explicitly in the spec. We could for instance say it's each client's responsibility (and not the server's responsibility) to pick valid content-types.
My gripe is less about unregistered content types than the redundancy of specifying how the syntax of a Content-Type should look like.
if we say it's the responsibility of the client to pick a valid content-type, then we can also remove the sentence that says it has to be an ASCII string.
That responsibility exists with normal HTTP usage so it would be a new redundant specification.
ok, so I would be fine with changing this paragraph to something like:
If not exactly one Content-Type header was received as part of a
PUT request or the Content-Type header value violates
https://tools.ietf.org/html/rfc7231#section-3.1.1.5 ,
the server MAY refuse to
process the request, and instead respond with a descriptive error
message in the body, and a http response code from the 4xx range.
Yeah that makes sense.