Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve 400 vs 415 #1

Closed
jpstroop opened this issue Feb 25, 2014 · 3 comments
Closed

Resolve 400 vs 415 #1

jpstroop opened this issue Feb 25, 2014 · 3 comments
Labels

Comments

@jpstroop
Copy link
Member

We should be more explicit about the 415 in section 4.5 if we think it's important to distinguish from other 400 errors codes. As just .../native is okay, and the server can do conneg, then 415 actually isn't the right error code, it should be 406 Not Acceptable.
Maybe we include a flowchart if we want to maintain the distinctions

Current: 415 - Format not supported
Alternatives: 406?
What about Conneg - 406 for that?
Spec says you may always return an image, even if in a different format.

@jpstroop jpstroop modified the milestone: Release 1.2 Feb 25, 2014
@jpstroop
Copy link
Member Author

See:

https://github.com/IIIF/specifications/blob/master/image_api/image_api_1.2.md#45-format

We worked on this in Copenhagen and decided to drop all 4xx language from this part of the spec. In 6.2 we added:

406 Not Acceptable | The server does not support the format requested by Content Negotiation. If the requested format is specified in the URI, and the server is not able to deliver it, then the appropriate error code is 400.

@zimeon
Copy link
Member

zimeon commented Feb 27, 2014

+1

@azaroth42
Copy link
Member

+1

On Thu, Feb 27, 2014 at 7:50 AM, Simeon Warner notifications@github.comwrote:

+1

Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-36248820
.

glenrobson pushed a commit that referenced this issue Jul 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants