Open Stack

... 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?

-Clay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160205/48be17a3/attachment.html>