Demian Brecht added the comment:
My concern about this is around the combination of the following two passages:
draft-ietf-httpbis-p2-semantics-14, Section 7.3:
> Bodies on GET requests have no defined semantics. Note that sending
> a body on a GET request might cause some existing implementations to
> reject the request.
RFC 7230, Section 3.3.2:
> The presence of a message body in a request is signaled by a Content-Length
> or Transfer-Encoding header field.
My concern around the above is the possibility that servers may have
implementations that reject requests with methods that are not expecting bodies
solely on the existence of the Content-Length header rather than the value
(which may be 0). Without a good amount of research around whether or not this
would be an actual problem in practice, I wouldn’t be comfortable adding
Content-Length header to every request.
> My feeling is that stripping out Content-Length for GET requests could cause
> problems for some code that for whatever reason uses this
That’s definitely a valid concern. What if the logic was tweaked a little:
expecting_len = method.upper() in _METHODS_EXPECTING_BODIES or \
body is not None
if expecting_len and 'content-length' not in header_names:
self._set_content_length(body)
That way, if someone is intentionally sending a body in a GET request, the
value of Content-Length would still be automatically added, but would still be
set to 0 for all other cases where bodies are expected.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue23539>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
