content-type with "+ convention" #172
Labels
Comments
|
That would also be more in line with RFC 7807's |
mnot
changed the title
|
Yes. I've intentionally not registered the media type because I want the flexibility to change the format when it's more baked. |
Closed
|
as one additional data point: https://tools.ietf.org/html/draft-wilde-home-xml-03#section-4.1 defines |
|
Seems like it's time to turn this convention into an officially meaningful thing. |
|
@RubenVerborgh: it is an RFC (https://tools.ietf.org/html/rfc6838), but media types are free to follow or ignore this pattern. |
cdent
added a commit
to cdent/gabbi
that referenced
this issue
Sep 2, 2021
Some formats that look like they might be JSON, based on the media-type in the content-type header are not actually valid JSON. This presents problems with tests trying to decode, but being unable to do so, causing unexpected failures. These changes update the accepts method in the JSONHandler to be more specific and adds tests to cover it. As part of this some test which showed that we accept "application/json-home" as valid JSON have been removed. That media type is not considered legitimate. See: mnot/I-D#172 Note that this change is an improvement, but it is not 100% reliable as there is no good way to be so because the world is complex and ambiguous, which is part of why #301 was done: to deal with gaps. Thanks to @FND for ideas from #298. Fixes #296
cdent
added a commit
to cdent/gabbi
that referenced
this issue
Sep 3, 2021
Some formats that look like they might be JSON, based on the media-type in the content-type header are not actually valid JSON. This presents problems with tests trying to decode, but being unable to do so, causing unexpected failures. These changes update the accepts method in the JSONHandler to be more specific and adds tests to cover it. As part of this some test which showed that we accept "application/json-home" as valid JSON have been removed. That media type is not considered legitimate. See: mnot/I-D#172 Note that this change is an improvement, but it is not 100% reliable as there is no good way to be so because the world is complex and ambiguous, which is part of why #301 was done: to deal with gaps. This change was driven by needing to not match 'application/json;stream=<some value>'. This is based on what Kubernetes does for watch requests, streaming json objects over chunks. Thanks to @FND for ideas from #298. Fixes #296
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I would have expected
application/home+jsonin line with the "+ convention".The text was updated successfully, but these errors were encountered: