On Wed, Jul 27, 2016 at 01:31:28PM +0200, Reyk Floeter wrote: > > > 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.
Sure, I should have splitted the diffs. > > >> > >> 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. Cool. Is the RFC3253 going to be merged to ? > > 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. Ok. I didn't notice that relayd had a security filtering focus. If so, enforcing presence/absence of body is legit. > > you wouldn't use "pfctl -d" to fix your firewall problems, of course. Obviously not. But only because pf is clearly here for filtering. I thought relayd main purpose was to relay so removing a simple filtering wasn't an issue. Regards, Paul > > 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 > -- Paul Fariello PGP: 0x672CDD2031AAF49B
