Project

General

Profile

Feature #2939

webdav should use HTTP204 instead HTTP404 on non-existing file

Added by katomaso 14 days ago. Updated 3 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
mod_webdav
Target version:
Start date:
2019-03-09
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

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?

requestor.html (1.78 KB) requestor.html HTML page with javascript doing XMLHttpRequests to a webdav endoint running lighttpd/1.4.53 katomaso, 2019-03-10 08:18

History

#1

Updated by gstrauss 13 days 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.

(see. https://stackoverflow.com/questions/14702962/can-an-http-options-request-return-a-204-or-should-it-always-return-200/31256072#31256072)

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.

#2

Updated by katomaso 13 days ago

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

#3

Updated by gstrauss 12 days 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.

#4

Updated by katomaso 3 days 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.

#5

Updated by gstrauss 3 days 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.

Also available in: Atom