Open Stack

Hi,

> -----Original Message-----
> From: Clay Gerrard [mailto:clay.gerrard at gmail.com]
> Sent: 2016 február 5, péntek 21:21
> To: OpenStack Development Mailing List <openstack-
> dev at lists.openstack.org>
> 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