Feature #2939
closedOPTIONS should return 2xx status for non-existent resources if Allow is set
Description
Hello,
the problem with this is CORS - more specifically preflight OPTIONS request. If a Web-based webdav client is trying to create a new file then browsers will always use preflight request to ensure CORS accordance. The problem is that 404 is regarded as CORS failure thus it is impossible to create new files.
I would propose to return HTT204 for non existing files and HTTP200 with empty content for existing but empty files. It is according to specification - maybe even better (see. https://stackoverflow.com/questions/14702962/can-an-http-options-request-return-a-204-or-should-it-always-return-200/31256072#31256072)
Would you accept such solution?
Files
Updated by gstrauss almost 6 years ago
- Tracker changed from Bug to Feature
If a Web-based webdav client is trying to create a new file then browsers will always use preflight request to ensure CORS accordance. The problem is that 404 is regarded as CORS failure thus it is impossible to create new files.
Which webdav client are you using? Sounds like a poor behavior in the client.
I would propose to return HTT204 for non existing files and HTTP200 with empty content for existing but empty files. It is according to specification
Citation needed
- maybe even better
No, nothing is better than the specification.
Did you read that link? Or just your additional comment there?
Are you aware how foolish you look making the judgement "Unfortunately, nginx and lighttpd has it wrong today and I am despair to find a good substitute for them" when you have not presented evidence to back that up? You have zero credibility. The last comment in that post before yours is almost 6 months ago, and the original question was posted just over 6 years ago. That you are at your wits end suggest you might not have started with much. That the nginx and lighttpd do not support the behavior you seek after 6+ years suggests that this is not a critical "bug" that is causing problems for many other people.
Would you accept such solution?
Maybe after you grow up a bit (or a lot) and stop insinuating that you know better than everyone else. Politely make a feature request suggesting a change in behavior, provide detailed information on how to reproduce the problem (including the client you are using), and back up your request with references to RFCs.
It sounds like you are requesting a feature that mod_webdav change its handling of "OPTIONS /path/to/webdav HTTP/1.1". Please be specific and precise.
Updated by katomaso almost 6 years ago
- File requestor.html requestor.html added
Hello,
thank you for a fast reply. First, I am sorry that I offended you.
Thank you for making my request clear - I indeed propose that "OPTIONS /path/to/webdav/nonexisting.file HTTP/1.1" should return 204 rather than 404 to allow CORS. It is my first real feature request so I will try to get better at it.
The webdav library is a javascript one running in a browser. Therefor it does not control how the request is made. The preflight request is made every time by the browser.
I created a simple page that sends the simpliest XMLHttpRequest to prove my point. Please find it in the attachments. It points to lighttpd/1.4.53 running on my server.
You can try the webdav editor in question.
$ git clone https://github.com/katomaso/webdave.git
Open webdave/docs/index.html in your browser - everything should work
Use credentials "guest" "guest" and point at the same place where the attached HTML page points. You can see that creating a new file (writing it in the input box) will fail on OPTIONS but if you manually edit the failed PUT request and re-send it then the file gets created. (If you want to edit an existing file you need to click it twice slowly - it is still a work in progress.)
Regards,
Tomas
Updated by gstrauss almost 6 years ago
Your example includes:
"scripts": {
"build": "./node_modules/.bin/webpack --config webpack.config.js"
}
Have you looked at the webpack library code?
the problem with this is CORS - more specifically preflight OPTIONS request. If a Web-based webdav client is trying to create a new file then browsers will always use preflight request to ensure CORS accordance. The problem is that 404 is regarded as CORS failure thus it is impossible to create new files.
Citation needed.
Second and last time I will ask for citations before cancelling this ticket. Provide links to the specifications to support your statements, or don't bother responding.
Updated by katomaso almost 6 years ago
Hello gstrauss,
what citation do you have in mind? Of course I looked in the code. That's why I have prepared the simple demo for you as an attachment to show the browser's behaviour.
Updated by gstrauss almost 6 years ago
Provide links to the specifications to support your statements
Was that unclear?
the problem with this is CORS - more specifically preflight OPTIONS request. If a Web-based webdav client is trying to create a new file then browsers will always use preflight request to ensure CORS accordance. The problem is that 404 is regarded as CORS failure thus it is impossible to create new files.
Citation needed.
Why is it unclear that you are not the arbiter of truth and that I am asking that you provide links to relevant sections of official specifications to support your statements? There is a difference between specifications and implementations, though there is hopefully much overlap. However, so far you have described the behavior of a single implementation in javascript (webpack).
Let me try to be more blunt:
webdav should use HTTP204 instead HTTP404 on non-existing file
Why? Because you said so? ==> Citation needed.
I would propose to return HTT204 for non existing files and HTTP200 with empty content for existing but empty files.
This statement from the description of this ticket does not properly differentiate between HTTP methods and is either imprecise or wrong. Let's give you the benefit of the doubt and say imprecise.
Updated by gstrauss over 5 years ago
- Subject changed from webdav should use HTTP204 instead HTTP404 on non-existing file to OPTIONS should return 2xx status for non-existent resources if Allow is set
- Status changed from New to Patch Pending
- Target version changed from 1.4.x to 1.4.54
Updated by gstrauss over 5 years ago
- Status changed from Patch Pending to Fixed
- % Done changed from 0 to 100
Applied in changeset 95aa2c178d6d61e1e42c99018d79993c66bc46e6.
Also available in: Atom