https://bugzilla.wikimedia.org/show_bug.cgi?id=36950
Platonides <platoni...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |platoni...@gmail.com
--- Comment #11 from Platonides <platoni...@gmail.com> 2012-05-22 14:09:31 UTC
---
(In reply to comment #9)
> To many things might use Content-Length for purposes other than the body
> length.
You mean violating RFC 2616?
" The Content-Length entity-header field indicates the size of the
entity-body, in decimal number of OCTETs, sent to the recipient or,
in the case of the HEAD method, the size of the entity-body that
would have been sent had the request been a GET."
> Also, HEAD requests, of course, shouldn't have this check.
It seems HEAD requests weren't skipped from the check, which is a bug.
You could also argue not adding it for status codes 1xx, 204, and 304 (but they
shouldn't have a non-zero Content-length. anyway)
> Like POSTing or PUTing to Swift/S3 will give a content-length of the
> data stored, not the response.
That's the content-length of the client request, not of the server reply, which
is what we're dealing with, here.
If the server replies the POST with the request size, that violates the HTTP
specification. How do you know the response length, then?
> Really, only the caller of the Http class can determine if the
> headers make sense for the body in this case.
The caller shouldn't need to manually check the content.
Reedy, can you provide the server headers in the reply to the output.rl POST?
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
