Hi, > -----Original Message----- > From: Clay Gerrard [mailto:[email protected]] > Sent: 2016 február 5, péntek 21:21 > To: OpenStack Development Mailing List <openstack- > [email protected]> > Subject: [openstack-dev] RFC 2616 was *so* 2010 > > ... really more like 1999, but when OpenStack started back in '10 - RFC 2616 > was the boss. > > Since then (circa '14) we've got 7230 et. al. - a helpful attempt to > disambiguate things! Hooray progress! > > But when someone recently opened this bug I got confused: > > https://bugs.launchpad.net/swift/+bug/1537811 > > > The wording is 7230 *is* in fact pretty clear - MUST NOT [send a content- > length header, zero or otherwise, with a 204 response] - but I really can't > find > nearly as strong a prescription in 2616. > > Swift is burdened with a long lived, stable API - which has lead to wide > adoption from a large ecosystem of clients that have for better or worse > often adopted the practice of expecting the API to behave the way it does > even when we might otherwise agree it has a wart here or there. > > But I'm less worried about the client part - we've handled that plenty of > times in the past - ultimately it's a value/risk trade off. Can we fix it > without > breaking anything - if we do break someone what's the risk of that fallout vs. > the value of cleaning it up now (in this particular example RFC 7230 is > equally > strongly prescriptive of clients, in that we should be able to say "content- > length: booberries" in a 204 response and a well behaved client is expected > to ignore the header and know that the 204 response is terminated with the > first blank line following the headers). Again, we've handled this before and > I'm sure we'll make the right choice for our project and broad client base. > > But I *am* worried about RFC 7230!? Is it reasonable that a HTTP 1.1 > compliant server according to 2616 could possibly NOT be a HTTP 1.1 > compliant server after 7230? Should the wording of this particular > prescription be SHOULD NOT (is that even possible?! I think I read > somewhere that RFC's can have revisions; but I always just pretend they're > like some sort of divine law which must be followed or face eternal scorn > from your fellow engineers) Maybe sending a "content-length: 0" header > with a 204 response was *never* tolerable (despite being descriptive and > innocuous), but you just couldn't tell you weren't conforming because of all > the reasons 7230 got drafted in the first place!? Does anyone know how to > get ahold of Mark Nottingham so he can explain to me how all this works? > As I mentioned in the bug report, the problem with disobeying RFC7230 is that some proxy will remove Content-Length for 204 answers, or even worse: it'll make the response invalid.
> -Clay //György __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
