> On 27.07.2016, at 12:41, Paul Fariello <[email protected]> wrote: > > On Wed, Jul 27, 2016 at 12:18:06PM +0200, Reyk Floeter wrote: >> >> What are you trying to do - removing this logic is obviously not how it was >> intended. >> I think you shouldn't send superfluous diffs. > > I'm just trying to help.
fair enough > Maybe it's the wrong mailing list for such mail > exchanges. Should I post it somewhere else ? > yes, but your diff fixed one thing by throwing something else away. >> >> The OPTIONS request doesn't have a body, but the OPTIONS response may have >> one. > > As I said RFC3253 seems to change the behavior of OPTIONS. See 6.4.1 > Example - OPTIONS: > OPTIONS has been fixed in relayd and httpd with Michael's diff now. tldr the OPTIONS body is an optional "future extension". (btw., please refer to the 723x RFCs for HTTP/1.1 now) >>> REQUEST > > OPTIONS /doc HTTP/1.1 > Host: www.webdav.org > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > > <?xml version="1.0" encoding="utf-8" ?> > <D:options xmlns:D="DAV:"> > <D:version-history-collection-set/> > <D:workspace-collection-set/> > </D:options> > >>> RESPONSE > > HTTP/1.1 200 OK > DAV: 1 > DAV: version-control,checkout-in-place,version-history,workspace > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > > <?xml version="1.0" encoding="utf-8" ?> > <D:options-response xmlns:D="DAV:"> > <D:version-history-collection-set> > <D:href>http://repo.webdav.org/his</D:href> > </D:version-history-collection-set> > <D:workspace-collection-set> > <D:href>http://www.webdav.org/public/ws</D:href> > <D:href>http://www.webdav.org/private/ws</D:href> > </D:workspace-collection-set> > </D:options-response> > > As far as I understand RFC2616 chapter 4.3. one should only consider > Content-Length or Transfer-Encoding for signaling the presence of a > body. IIUC it's what the default does in the switch(desc->http_method). > > RFC2616 also states that a server should read and forward a message-body > on any request. > and here I disagree, neither relayd nor httpd are going to let everything through. you wouldn't use "pfctl -d" to fix your firewall problems, of course. and, quite frankly, HTTP extensions that introduce new methods are relatively rare. WebDAV is the only relevant, but horrible, extension that we really have to handle. so we can deal with them in an explicit way. Reyk > I think it makes it easier for relayd to just ignore whether an http > method is defined to have a body and just use Content-Length. This way > relayd can easily support some http extension. > > It's what my patch intended to do. > >> And there is the difference to httpd - relayd has to handle both sides. >> >> So a proper fix would be to handle the methods for request and response >> differently - >> the webdav diff that I sent before is only part of the fix. > > Sorry, I missed your patch. > > -- > Paul Fariello > > PGP: 0x672CDD2031AAF49B
