We have a WebDAV servlet in place and are starting to get MS Word up and running against it. We have OPTIONS and PROPFIND and GET. Do you know of other verbs that Word will be requesting?
According to RFC 2518, you will have to support LOCK, UNLOCK, PROPFIND, PROPPATCH, COPY, MOVE, MKCOL verbs.
If you need to save documents to server from MS office only OPTIONS, PROPFIND and GET would not be enough.
Here is the list that you need to implement: GET, HEAD, LOCK, OPTIONS, PROPFIND, PROPPATCH, PUT, UNLOCK
RFC 2518 is replaced by RFC 4918.
Related
what are the HTTP idempotent and non-idempotent methods available as per RFC7231 by group?
methods:
GET, POST, PUT, OPTIONS, HEAD, DELETE, TRACE, CONNECT
Idempotent http methods:
GET, PUT, OPTIONS, HEAD, DELETE, TRACE
Non-Idempotent http methods:
POST, CONNECT
Reference:
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
I am building a file service support WebDAV protocol from scratch using ASP.NET WebAPI. The first step is to response to the OPTIONS request from WebDAV client (i used MS Office 2010 in this case). When got that request, my service will return these information (captured by Fiddle 2). The service is run under IIS server.
The service allows MS Office to open the file at this url: https://fileservice.domain.com/api/OfficeClient?dir=C:\Test\WebApi.docx
HTTP/1.1 200 OK
Allow: COPY,DELETE,GET,HEAD,LOCK,MOVE,OPTIONS,POST,PROPFIND,PROPPATCH,PUT,REPORT,UNLOCK
Content-Length: 0
Accept-Ranges: bytes
Server: Microsoft-IIS/7.5
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: ACL, CANCELUPLOAD, CHECKIN, CHECKOUT, COPY, DELETE, GET, HEAD, LOCK, MKCALENDAR, MKCOL, MOVE, OPTIONS, POST, PROPFIND, PROPPATCH, PUT, REPORT, UNCHECKOUT, UNLOCK, UPDATE, VERSION-CONTROL
Access-Control-Allow-Headers: Overwrite, Destination, Content-Type, Depth, User-Agent, Translate, Range, Timeout, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control
Access-Control-Max-Age: 2147483647
DAV: 1
Public: COPY, DELETE, GET, HEAD, LOCK, MOVE, OPTIONS, POST, PROPFIND, PROPPATCH, PUT, REPORT, UNLOCK
MS-Author-Via: DAV
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 29 May 2013 04:36:19 GMT
The problem is that, MS Office kept sending 5 same OPTIONS request. The next request it is supposed to send should be HEAD, and then a series of other methods to open a document.
I do have a look at: http://sourceforge.net/projects/webdav/?source=navbar implementation. And also try to run demo from http://www.webdavsystem.com/server/ and look at the Fiddle. But i cannot find any differences in my example and the online demo.
I managed to solve the issue. It is the URL issue and lot of other stuff. I cannot write down the detail here since it is a complex implementation. Just want to make sure that noone will waste time on trying to answer the question.
The HTTP OPTIONS method is supposedly used to determine what other methods the server supports on a given resource. Given that, I have two questions:
What does this response look like? I have seen examples with CSV lists in Public, Allow, and even Access-Control-Allow-Methods headers. Are they all needed? What's the difference? RFC 2616 doesn't seem to be very helpful here.
Would it be appropriate to use this to list the actions that a resource supports in a non-REST-API environment? For example, if my ConversionController supports the action convert, would a response like this make sense:
Request:
OPTIONS /conversion HTTP/1.1
Response:
HTTP/1.1 200 OK
...
Allow: CONVERT
...
RFC 2616 defines "Allow" (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7). "Public" is not in use anymore. "Access-Control-Allow-Methods" is defined in the CORS specification (see http://www.w3.org/TR/cors/).
What is an HTTP OPTIONS request?
It is a request from the client to know what HTTP methods the server will allow, like GET, POST, etc.
Request
The request might look like this when asking about the options for a particular resource:
OPTIONS /index.html HTTP/1.1
or like this when asking about the server in general:
OPTIONS * HTTP/1.1
Response
The response would contain an Allow header with the allowed methods:
Allow: OPTIONS, GET, HEAD, POST
Why is the server receiving an HTTP OPTIONS request?
Some REST APIs need it (but if you are defining the API, you'd know that)
Browsers send it to servers as "preflighted" requests to see if the server understands CORS
Attackers send it to get more information about the API
How to respond to an HTTP OPTIONS request?
You could respond with an Allowed header and even document your API in the body.
You could respond with additional CORS defined Access-Control-Request-* headers.
You could respond with 405 Method Not Allowed or 501 Not Implemented.
How do I stop getting HTTP OPTIONS requests?
If it's coming from a browser then update your API so that it isn't doing anything "dangerous" (like PUT or DELETE, or POST with application/json). Only perform simple requests.
See also
RFC 2616 Section 9: Method definitions
MDN Web docs: OPTIONS
MDN Web docs: Cross-Origin Resource Sharing (CORS)
CORS - What is the motivation behind introducing preflight requests?
How to exploit HTTP Methods
In response to the title: "How to respond to an HTTP OPTIONS request?" To answer that, I'd want to know why you want to respond to an OPTIONS request? Who/what is sending you an OPTIONS request, and why? Many public servers respond with some form of "error" or "not allowed" (500, 501, 405). So, unless you're in a specific situation where your clients will be reasonably sending OPTIONS requests and expecting useful/meaningful information back (e.g., WebDAV, CORS), you probably want to respond with: "don't do that."
In terms of your question about the "OPTIONS /conversion HTTP/1.1" request: unless you know that there's some client of your server, a client which would send an OPTIONS request to "/conversion" and expect a response with "Allow: CONVERT," the answer is no: it wouldn't make sense to respond like that. I think that most implementations that do support OPTIONS and respond with "Allow," respond with standard HTTP methods.
Here's a great article on the topic.
Summary: OPTIONS is immediately problematic because it doesn't support caching. Alternatives: server-wide metadata: try well-known URI's. Resource-specific: try using a Link header on its responses, or a link in the representation format for that resource.
Lastly, if what you're after is a service description, have a look at WADL or RSDL.
EDIT:
dotnetguy makes a good point in the comment below: OPTIONS is undeniably valuable in certain contexts (e.g., CORS); I certainly didn't mean to suggest otherwise.
or more specifically, please recommend me some name conventions for URIs designed to delete and update resources. What I am using is something like "POST resource/id/delete" and "POST resources/", but I am there must be better ways to do that.
Thanks.
Since HTML does not support HTTP DELETE, you can POST to the resource, say, /resources/13 with a query string parameter to define the intent: POST /resources/13?_method=DELETE HTTP/1.1
In the case of updating a resource, you could do POST resources/13?_method=PUT HTTP/1.1, assuming of course that your intent will match the proper semantics of PUT, which is to place a complete and entire entity at the specified URI.
A very important thing to remember is that 'delete' is not a resource, and so it makes no sense to have a resource identifier for it. Delete is a verb, which is what HTTP methods are for. Of course, we can all hope that one day HTML will support HTTP entirely instead of just some arbitrary verbs.
According to RFC 2616, generation of entity tags by HTTP servers is optional. However, I couldn't find what a conditionally compliant HTTP server should do if it receives an If-Match (or If-None-Match) header. Should it just ignore those headers or should it respond with 412 Precondition Failed?
UPD: Just to clarify, I'm assuming that the server in question does not support entity tags.
In contrast to an If-None-Match header (ignorance of which only harms performance), an IF-MATCH request should almost certainly fail and return a HTTP/412 if the server cannot match the requested entity. Probably the most common use of the IF-MATCH header is when the client is doing a Range request, and unless the server can confirm that the resource was not modified, it should not return the requested range because the result could be data corruption on the client.
Now, if the server knows it's not a Range request or knows that the client entity must, in fact, match (e.g. because the server never allows updates to its entities) then acting as if the header wasn't present may make sense in that limited circumstance.
There is a handy HTTP response status codes activity diagram that you can use to answer this question.
If you don’t support ETag and the request contains a If-Match value other than *, you would respond with a 412. And If-None-Match with values other than * can be completely ignored.
While the RFC2616 is implicit on the matter, you can deduce from, say 14.26 (If-None-Match), that if the server cannot match the resource with the tag, then it should go ahead with request). The 412 code, based upon my understanding of RFC2616 is intended for requests which modify state (e.g. PUT, POST, DELETE).
So, in essence, if the tag doesn't match (and when it's absent on server side is only one of many possible scenarios), then the server should go ahead with the request.