-
Notifications
You must be signed in to change notification settings - Fork 341
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
204 and json #113
Comments
I don't think we want to intertwine stream consumption as a particular type with semantics of the response. E.g., we don't check |
I agree it's not something you'd want to do in general for all content types, but given that the decision has been made to have a |
We don't do anything special for |
In theory a 204 should have a null body, right? In that case, we can probably detect this condition with if(response.body) once streams are integrated. |
Yes. Closing this since I don't think we want these methods to have this kind of dependency. |
Hey, I want to follow up on @wanderview's comment:
Does any browser currently does this? As in, do any of them handle |
i think that ,do not interwine the content-type is a good job |
Any new thoughts on best practices to handle this? |
async function getJSON(response) {
if (response.status === 204) return '';
return response.json();
} |
I'm dealing with GitHub's followers API and it returns empty responses as 404 or 204. This is my solution: const content = await response.text();
const json = content.length > 0 ? JSON.parse(content) : {}; // or : response.ok Aside: I think that fetch's behavior is correct and APIs are breaking the contract by not sending valid JSON when the user expects it ( |
Or, just check the status as in #113 (comment). Or: |
I was responding exactly to that, empty requests might have statuses other than 204. Also |
If we consider: const data = await (/^application\/json/.test(r.headers.get('content-type'))
? r.json()
: r.text()); since we can't consume the body twice, we can't do a And since content-type is not fully reliable, is it better to do do? let data = await r.text();
try {
data = JSON.parse(data);
} catch {} in terms of performance? of readability, etc. I know an answer would be to ensure the server always return json responses (or empty with/without the right 204 statusCode), but it's not always the case I see why the idea of |
Well, that really depends on the application and to what extent the signals from the server are significant. E.g., processing a response without We could perhaps introduce something akin to |
New here and just ran into this, what's the community answer to deal with a json POST request that returns 204 No Content? Just check response code? |
const r = await fetch('https:...', { method: 'POST', .. });
if (r.ok) {
const data = await r.json().catch(() => null);
// ...
} |
I would go with this approach. But if it's something that needs to be done always, it could just be integrated in the call to |
…iding passing through the catch I found this solution here whatwg/fetch#113 (comment)
…iding passing through the catch I found this solution here whatwg/fetch#113 (comment)
…iding passing through the catch I found this solution here whatwg/fetch#113 (comment)
When a Response is
204
andresponse.json()
is called anunexpected end of input
error is thrown.As the response is already stating that there is no JSON trying to parse it feels wrong. Would it make more sense in this case to either:
a) resolve with an empty value
b) throw a more informative error e.g.
Cannot parse a response with no content as json
The text was updated successfully, but these errors were encountered: