-
Notifications
You must be signed in to change notification settings - Fork 102
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
100 Continue on PATCH requests #152
Comments
Good catch. The reason for removing that paragraph was (if I recall correctly) that the wording was a bit off:
You can understand the sentence that the server should always send a Would you mind opening a PR to add a better paragraph back in the specification? |
Sure, can do. I also have a fix for the tusd server to return error responses instead of Although this is less useful than I had originally hoped, it turns out nginx is hardcoded to always respond with |
Awesome. Feel free to open a PR for it and we can discuss it!
That's interesting and sad at the same time. Do you have a link or resource to get more information about this limitation? |
Here's a couple of discussions on the nginx behaviour and the relevant code https://github.com/nginx/nginx/blob/3ba88365b5acef17f01671cd969c909dee5e2cde/src/http/ngx_http_request_body.c#L833 PR for the tusd change: tus/tusd#377 |
Thank you very much for the links and the PR! |
Is there a reason
Expect: 100-continue
is no longer mentioned as part of the PATCH request part of the upload flow? Only as part of the creation with upload extensionIt looks like it used to be in there after #9 but is now missing.
The tusd reference server also sends
HTTP/1.1 100 Continue
responses to invalid PATCH requests that do include the Expect header.It seems like supporting this would be a useful feature allowing errors to be nicely returned to clients without having to drop the connection or cause issues with intermediary proxies etc
The text was updated successfully, but these errors were encountered: