[PATCH]

[Igor Sysoev]

On Sun, May 20, 2007 at 06:44:13PM +0000, Evan Miller wrote:

> Igor Sysoev <is at ...> writes:
> 
> > On Sun, May 20, 2007 at 08:25:02AM +0000, Evan Miller wrote:
> > 
> > > Igor Sysoev <is <at> ...> writes:
> > > 
> > > > Thank you for your patch, however, I do not see any practical use of the
> > > > "Allow" header line. Yes, it must be set according to HTTP/1.1, but is
> > > > there any client that can use this information ?
> > > 
> > > I needed it (and wrote the patch) when I was using davfs, a WebDAV client.
> > > Other
> > > WebDAV clients might also use it, but I'm not sure. That being said, I don't
> > > actually need the functionality now, but I figured someone else might, and
> > > standards compliance seems like a good goal.
> > 
> > So, webfs uses this header ? How ?
> > 
> 
> IIRC, davfs looks for this header when it issues the OPTIONS method. However,
> the client I was using also required other headers in the OPTIONS response,
> including a "DAV" header (see
> http://www.webdav.org/specs/rfc2518.html#HEADER_DAV), but I lost interest before
> implementing those properly.
> 
> I honestly can't think of a compelling use-case aside from that, so for me it's
> just a question of standards-compliance. I'm a bit conflicted when it comes to
> standards; the do give clients predictability about the server's features, but
> some of the requirements (such as this one) don't add much value. My feeling is
> that if it's simple to do, you might as well support the standard; otherwise,
> don't bother. Here it was simple.

Yes, response for "OPTIONS * HTTP/1.1" must have the "Allow"ed methods,
however, this has no relation to 405 code. nginx does not support OPTIONS
method, so it may be only proxied and backend should set "Allow" header,
and nginx will send transparantly.


-- 
Igor Sysoev
http://sysoev.ru/en/