[issue23350] Content-length is incorrect when request body is a list or tuple

Vincent Alquier added the comment: Martin: You're right, it's the same issue, and only related to python2's old style classes. Sorry for the useless noise. Demian: My problem is `len(obj)` raises an Using AttributeError in python2 (with obj being old style class instance). It's python 2.X spec

[issue23350] Content-length is incorrect when request body is a list or tuple

Demian Brecht added the comment: Vincent: The logic to determine content length is undergoing a bit of an overhaul as part of #12319, which I'm hoping to wrap up in the next week or so. -- ___ Python tracker _

[issue23350] Content-length is incorrect when request body is a list or tuple

Martin Panter added the comment: Vincent: That sounds more like a case of Issue 15267, or have you found a way to trigger the AttributeError in Python 3 as well? -- ___ Python tracker _

[issue23350] Content-length is incorrect when request body is a list or tuple

Vincent Alquier added the comment: Another issue should be addressed by patch... When trying to guess the content-length, here is the code you find... try: thelen = str(len(body)) except TypeError as te: [...] The call to `len` will raise a `TypeError` i

[issue23350] Content-length is incorrect when request body is a list or tuple

R. David Murray added the comment: See also issue 12327 for length issue using StingIO. -- ___ Python tracker ___ ___ Python-bugs-list

[issue23350] Content-length is incorrect when request body is a list or tuple

Demian Brecht added the comment: If #12319 is accepted, the implementation for Content-Length should also likely be migrated to this issue to be applied to maintenance branches as a bug fix. -- status: pending -> open ___ Python tracker

[issue23350] Content-length is incorrect when request body is a list or tuple

Demian Brecht added the comment: The computation of Content-Length has also undergone some refactoring as part of #12319. Setting this as pending until #12319 has been accepted or rejected. If rejected, the implementation specific to generating Content-Length should be migrated here.

[issue23350] Content-length is incorrect when request body is a list or tuple

Demian Brecht added the comment: @Serhiy: > Content-Length shouldn't be calculated for lists, tuples, and other > non-bytes-compatible sequences. I'd agree with this if it wasn't relatively trivial to calculate. There's no reason that I can think of to exclude the auto-generated Content-Length

[issue23350] Content-length is incorrect when request body is a list or tuple

Martin Panter added the comment: David: Calculating the length of a list or tuple of Latin-1 text strings should actually be straight-forward and reliable, because it is a single-byte encoding. However I am starting to think adding a new special case for lists and tuples is a bad idea. There a

[issue23350] Content-length is incorrect when request body is a list or tuple

R. David Murray added the comment: Well, the current reality not counting the bug reported in this issue. So, I documented it as if the fix here is to not set the length when body is an iterator. -- ___ Python tracker

[issue23350] Content-length is incorrect when request body is a list or tuple

R. David Murray added the comment: I just updated the docs to what I think is the current reality. See issue 23740 for what I think are problems with the current implementation, aside from any enhancement of computing a length for tuple or list. Since the latter cannot be done reliably unles

[issue23350] Content-length is incorrect when request body is a list or tuple

Martin Panter added the comment: Technically I don’t think there is a bug. The documentation says [the] “Content-Length header should be explicitly provided”, so if you don’t set it you could argue that you’re using the library wrong. For this issue I think Demian was trying to add support (i.

[issue23350] Content-length is incorrect when request body is a list or tuple

Serhiy Storchaka added the comment: There are two issues. The one is that calculated Content-Length is not correct for lists, tuples, and other types (such as deque or array.array). The right solution is to calculate size using a technique used in urllib. Content-Length shouldn't be calculated

[issue23350] Content-length is incorrect when request body is a list or tuple

Changes by Berker Peksag : -- nosy: +berker.peksag stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue23350] Content-length is incorrect when request body is a list or tuple

Martin Panter added the comment: New patch looks good I think. Making the encoding code more consistent is nice. -- ___ Python tracker ___ ___

[issue23350] Content-length is incorrect when request body is a list or tuple

Demian Brecht added the comment: Thanks for the review Martin, I've addressed your comments. > The length of an encoded Latin-1 string should equal the length of the > unencoded text string, since it is a one-to-one character-to-byte encoding. Once in a while, I want to stop what I'm doing, put

[issue23350] Content-length is incorrect when request body is a list or tuple

Martin Panter added the comment: The length of an encoded Latin-1 string should equal the length of the unencoded text string, since it is a one-to-one character-to-byte encoding. So encoding should not actually be needed to determine the Latin-1 encoded length. Though I’m not particularly exc

[issue23350] Content-length is incorrect when request body is a list or tuple

Demian Brecht added the comment: Thanks for the clarification Martin. After giving this some further thought, I think that the best way to go is to /only/ calculate and add the Content-Length header if each element in the list or tuple is pre-encoded. If it's mixed or only strings, then there

[issue23350] Content-length is incorrect when request body is a list or tuple

Martin Panter added the comment: Sorry my comment was a bit rushed. I wasn’t saying this feature shouldn’t be added. I guess I was pointing out two things: 1. Someone should updated the documentation to say that Content-Length no longer has to be explicitly provided for lists and tuples. 2. P

[issue23350] Content-length is incorrect when request body is a list or tuple

Demian Brecht added the comment: On 2015-01-29 9:51 PM, Martin Panter wrote: > The documentation currently says “Content-Length header should be explicitly > provided when the body is an iterable”. See Lib/urllib/request.py:1133 for > how it is done for urlopen(), using memoryview(), which is p

[issue23350] Content-length is incorrect when request body is a list or tuple

Martin Panter added the comment: [Edit Error: 'utf8' codec can't decode byte 0xe2 in position 207: invalid continuation byte] The documentation currently says “Content-Length header should be explicitly provided when the body is an iterable”. See Lib/urllib/request.py:1133 for how it is done

[issue23350] Content-length is incorrect when request body is a list or tuple

Changes by Martin Panter : -- nosy: +vadmium ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue23350] Content-length is incorrect when request body is a list or tuple

Demian Brecht added the comment: Updated patch based on review. -- Added file: http://bugs.python.org/file37915/list_content_length_1.patch ___ Python tracker ___ ___

[issue23350] Content-length is incorrect when request body is a list or tuple

Changes by Antoine Pitrou : -- nosy: +orsenthil ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue23350] Content-length is incorrect when request body is a list or tuple

Changes by Demian Brecht : -- components: +Library (Lib) type: -> behavior versions: +Python 3.5 ___ Python tracker ___ ___ Python-bu

[issue23350] Content-length is incorrect when request body is a list or tuple

New submission from Demian Brecht: Rather than summing the value of each element of a list or tuple to use as the value of the content-length header, the length of the list or tuple is used. -- files: list_content_length.patch keywords: patch messages: 235012 nosy: demian.brecht priorit