Demian Brecht added the comment:
> I'm happy to produce a patch if there's any chance it would be merged.
If the patch adheres to the RFC, then I see no reason why it shouldn't be
merged. What makes this a little more tricky than the snippet that you included
in your post t
Demian Brecht added the comment:
Attached is a fix that ignores the entire invalid cookie as defined in RFC
6265, Section 5.2. I'm also attaching patches for maintenance branches as it's
a valid bug (NAME=VALUE pairs are required across all RFCs), although it would
break
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38261/issue23138_34.patch
___
Python tracker
<http://bugs.python.org/issue23138>
___
___
Python-bug
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38262/issue23138_27.patch
___
Python tracker
<http://bugs.python.org/issue23138>
___
___
Python-bug
New submission from Demian Brecht:
#14721 solved setting the Content-Length header for 0-length bodies. However,
it doesn't account for cases where body is None (reported by James Rutherford
here: http://bugs.python.org/issue14721#msg236600).
One method of solving this might be something
Demian Brecht added the comment:
Thanks for the heads up Ned.
James: I've created #23539 in the event that you'd like to contribute a patch.
--
___
Python tracker
<http://bugs.python.o
Demian Brecht added the comment:
> I'm assuming this affects all Python 3.X versions but I've specifically
> encountered it on Python 2.7.
Unless there are any core dev objections, I think it's applicable to 2.7, 3.4
and 3.5 as other minor 3.x versions are in
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 ex
Demian Brecht added the comment:
> The logic now is as it was before, except that we set a content length of
> zero if the body is None and the method is one of OPTIONS, PATCH, PUT, or
> POST.
I see we definitely have similar thinking on the modifications required for
this, but I do
Demian Brecht added the comment:
LGTM. I'm not sure whether or not it's eligible for 3.4 though as it's a
documentation and not a functional fix.
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.
Demian Brecht added the comment:
> Also, I think OPTIONS should be removed from the list of methods that enforce
> a Content-Length. I wouldn’t normally expect any payload for OPTIONS, since
> RFC 7231 explicitly says it does not define a use for a payload, but requires
> a Conte
Demian Brecht added the comment:
> My feeling is that '' implies "present but empty" (so should have a
> content-length set to zero), whereas None implies "missing" (so should only
> have a content-length header set to zero if the method is expect
Demian Brecht added the comment:
> I actually consider this a fix for the fix in 14721, rather than a new
> feature.
+1
--
___
Python tracker
<http://bugs.python.org/i
Demian Brecht added the comment:
> but I wonder if that goes beyond the scope of this issue?
I think it’s worthwhile to fix it while you’re already working on the logic
there. I’d consider Content-Type being set for methods not expecting it as a
(very) minor bug and it’s better to clear
Demian Brecht added the comment:
+David, Senthil: Thoughts on this?
--
nosy: +orsenthil, r.david.murray
___
Python tracker
<http://bugs.python.org/issue23
Demian Brecht added the comment:
> Aside from that, however, I see request.('GET', '/') and request.('GET', '/',
> '') as clearly *different* from an API call standpoint, so I would in any
> case preserve the existing behavior.
I do u
Demian Brecht added the comment:
> OK, sounds like we're approaching consensus? And I believe that the patch
> as-is captures that consensus
Yes, I believe that we’ve reached a consensus and that your patch captures it.
Thanks f
Changes by Demian Brecht :
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue23539>
___
___
Python-bugs-list mai
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23576>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
I've attached a patch that implements full Transfer-Encoding support for
requests as specified in RFC 7230.
--
___
Python tracker
<http://bugs.python.org/is
Demian Brecht added the comment:
I hit "submit" a little too soon.
The intention of the patch is to adhere to all aspects of Transfer-Encoding as
specified in the RFC and to make best guesses as to encoding that should be
used based on the data type of the given body.
This
Changes by Demian Brecht :
--
versions: +Python 3.5 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue12319>
___
___
Python-bugs-list mailing list
Unsub
Demian Brecht added the comment:
Also note that this patch includes the changes in #23350 as it's directly
relevant.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38352/issue12319_1.patch
___
Python tracker
<http://bugs.python.org/issue12319>
___
___
Python-bug
Demian Brecht added the comment:
Not to throw a wrench into this, but would it perhaps not be worthwhile to
refactor this section in order to include nonlocals as well (obviously not for
2.7)? It seems a little odd to me to have this amount of detail without
mentioning nonlocal
Demian Brecht added the comment:
I think some further consideration around this change is worthwhile:
Currently, urllib.parse.split* methods seem to do inconsistent validation
around the data they're splitting. For example:
(None for an invalid port)
>>> parse.splitnport(&#
Changes by Demian Brecht :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue20271>
___
___
Python-bugs-list mailing list
Un
Demian Brecht added the comment:
> splitport() shouldn't handle auth, it should be called after auth is dropped
> with splituser().
Why shouldn't splitport() handle auth? Are you suggesting that in the eyes of
splitport() that "user:password@host:port" should be inv
Demian Brecht added the comment:
LGTM
--
nosy: +demian.brecht
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue20557>
___
_
Demian Brecht added the comment:
LGTM
--
nosy: +demian.brecht
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue20556>
___
_
Demian Brecht added the comment:
I'm on OSX 10.10.2. Simply copy/pasting the line into both terminal and iterm
yields
>>> [“Test”][‘Test’]
File "", line 1
[“Test”][‘Test’]
^
SyntaxError: invalid character in identifier
>>> [“Test”][‘Test’]
F
Demian Brecht added the comment:
> It is surprising that urlsplit() does not raise any exception
I have a bit of a TL;DR in #20271, trying to capture what the responsibilities
of split and parse methods in urllib are and what they should be if consistency
is something that we'
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22852>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue1508475>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23328>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
FWIW, so far I've tested this change against:
cherrypy 3.6.0
uwsgi 2.0.9 (--http-raw-body)
nginx 1.6.2 (chunked_transfer_encoding on, proxy_buffering off;) + uwsgi 2.0.9
(--http-raw-body)
The chunked body works as expected. Unfortunately, all implementa
Demian Brecht added the comment:
After sleeping on this, I think that the best route to go would be to drop the
trailer implementation (if it's not practical it doesn't belong in the standard
library).
Also, to better preserve backwards compatibility it may be better to circu
Demian Brecht added the comment:
After a chat with David and getting my head wrapped more around backwards
compatibility, I also agree that the changes in the patch are far too strict.
It's much more important to preserve backwards compatibility than to strictly
conform to the RFC.
Demian Brecht added the comment:
I agree that the current implementation doesn't conform to standards, but do
you think those cases are worth fixing as they can potentially break backwards
compatibility? I think that the reported case makes sense to fix as the
name/value pair are ent
Demian Brecht added the comment:
New patch addresses most review comments. Thanks for the review Serhiy.
--
Added file: http://bugs.python.org/file38410/issue2211_1.patch
___
Python tracker
<http://bugs.python.org/issue2
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue19547>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
Removed file: http://bugs.python.org/file38261/issue23138_34.patch
___
Python tracker
<http://bugs.python.org/issue23138>
___
___
Python-bug
Changes by Demian Brecht :
Removed file: http://bugs.python.org/file38262/issue23138_27.patch
___
Python tracker
<http://bugs.python.org/issue23138>
___
___
Python-bug
Demian Brecht added the comment:
It very well could be. I'd like to be able to repro it first though. I'll try
to get some time to look into it, but if someone else can confirm this behavior
and attach a test case, that would be great.
--
stage: ->
Demian Brecht added the comment:
> I think that for consistency either parse empty name-value pair as key="",
> value=None
There is already a test present
(https://hg.python.org/cpython/file/0469af231d22/Lib/test/test_http_cookiejar.py#l1084)
that ensures an unset name/value
Changes by Demian Brecht :
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue23138>
___
___
Python-bugs-list mai
Demian Brecht added the comment:
Latest patch should address all comments.
--
Added file: http://bugs.python.org/file38432/issue2211_2.patch
___
Python tracker
<http://bugs.python.org/issue2
Demian Brecht added the comment:
Latest patch should now address all comments.
--
Added file: http://bugs.python.org/file38433/issue22928_5.patch
___
Python tracker
<http://bugs.python.org/issue22
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38449/issue22928_6.patch
___
Python tracker
<http://bugs.python.org/issue22928>
___
___
Python-bug
Demian Brecht added the comment:
Thanks for the tweaks Serhiy, those seem reasonable to me.
--
___
Python tracker
<http://bugs.python.org/issue22928>
___
___
Pytho
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38464/issue23138_2.patch
___
Python tracker
<http://bugs.python.org/issue23138>
___
___
Python-bug
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38466/issue2211_3.patch
___
Python tracker
<http://bugs.python.org/issue2211>
___
___
Python-bugs-list m
Changes by Demian Brecht :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue22852>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue9679>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38476/issue2211_4.patch
___
Python tracker
<http://bugs.python.org/issue2211>
___
___
Python-bugs-list m
Demian Brecht added the comment:
Here's a simple patch that adds functionality matching that in http.client to
urllib.request. As pointed out by John, I see no reason why urllib and
http.client shouldn't have consistent handling if IDNs independent of IRIs
(although IRI encoding
Changes by Demian Brecht :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue9679>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38509/issue2211_5.patch
___
Python tracker
<http://bugs.python.org/issue2211>
___
___
Python-bugs-list m
Demian Brecht added the comment:
I've done an initial pass in Rietveld and left some comments, mostly around
docs. Here are some additional questions though:
Given has_* flags can be inferred during instantiation of *Result classes, is
there a reason to have them writable, meaning is th
Demian Brecht added the comment:
>>>> urlsplit("evil.com").netloc
> ''
>>>> urlsplit("evil.com").has_netloc
> True
>>>> urlunsplit(urlsplit("evil.com")) # Adds “//” back
> 'evil.com'
Demian Brecht added the comment:
> I avoided making them positional parameters, as they are not part of the
> underlying tuple object.
Ignore me, I was off my face and you're absolutely correct.
--
___
Python tracker
<http://b
Demian Brecht added the comment:
> I cannot imagine some existing code (other than an exploit) that would be
> broken by restoring the empty “//” component; do you have an example?
You're likely right about the usage (I can't think of a plausible use case at
any rate).
Demian Brecht added the comment:
+1 to the change, but I'd propose maybe "value of *scheme*" given the tables
are inline with both urlsplit and urlparse docs?
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.pyt
Demian Brecht added the comment:
Thanks for the report Mark, updating this patch to be more backwards compatible
was on my to-do list. I've attached a new patch that simply adds the new
characters to the legal value set.
It does look like that's the commit that introduced this issu
Changes by Demian Brecht :
Removed file: http://bugs.python.org/file38522/issue22931_1.patch
___
Python tracker
<http://bugs.python.org/issue22931>
___
___
Python-bug
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38525/issue22931_1.patch
___
Python tracker
<http://bugs.python.org/issue22931>
___
___
Python-bug
Demian Brecht added the comment:
Updated patch changes the following:
+ Removes support for trailers in requests as they're not supported
+ If Transfer-Encoding is explicitly set by the client, it's assumed that the
caller will handle all encoding (backwards compatibility)
+ Fixed a
Demian Brecht added the comment:
Thanks for the updates Serhiy. All look good to me.
--
___
Python tracker
<http://bugs.python.org/issue2211>
___
___
Python-bug
Changes by Demian Brecht :
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue2211>
___
___
Python-bugs-list mai
Demian Brecht added the comment:
> I haven’t heard any arguments against this option yet, and it didn’t break
> any tests.
Pre patch:
>>> urljoin('mailto:foo@', 'bar.com')
'bar.com'
Post patch:
>>> urljoin('mailto:foo@', '
Changes by Demian Brecht :
--
stage: -> patch review
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue18828>
___
___
Python-bugs-list mai
Demian Brecht added the comment:
Thanks for the follow up Serhiy, LGTM.
--
___
Python tracker
<http://bugs.python.org/issue2211>
___
___
Python-bugs-list mailin
Demian Brecht added the comment:
Nice work tracking down the commit, thanks for that. I've attached a fix.
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file38563/issue23703.patch
___
Python tracke
Demian Brecht added the comment:
>>>> urljoin('mailto:foo@', 'bar.com')
> 'mailto:bar.com'
>
> which seems fairly sensible to me.
This is where joining arbitrary protocols gets tricky. Does it make sense to
merge non-hierarchical protocols su
Demian Brecht added the comment:
Also, I would suggest still including the doc changes proposed by Madison in
all versions prior to 3.5.
--
___
Python tracker
<http://bugs.python.org/issue18
Demian Brecht added the comment:
Yep, that's a lot cleaner and tests pass. I've updated the patch with that
line. Thanks.
--
Added file: http://bugs.python.org/file38573/issue23703_1.patch
___
Python tracker
<http://bugs.python.o
Demian Brecht added the comment:
The attached patch reverts back to the old set() API, ignoring the parameter
and adding a deprecation warning. I've also added a few versionchanged and
deprecated tags in the Morsel docs. Other than the deprecation note in
whatsnew/3.5.rst that was added
Demian Brecht added the comment:
One super minor comment left in Rietveld (py3 patch). Otherwise LGTM.
--
___
Python tracker
<http://bugs.python.org/issue23
Demian Brecht added the comment:
> idmap was removed in 14b65de9b798, translate was removed in 99027c2b3fd2 when
> their became unnecessary.
I'd venture to say they slipped through the cracks. Following the deprecation
procedure here would be favourable IMHO as to give users a
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23662>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Demian Brecht added the comment:
FWIW, I've done some additional work to request/send in issue #12319 where I've
added support for chunked request encoding.
@David
> if an iterable is passed in, it must be an iterable of bytes-like objects
This specific issue is addressed in
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38670/issue12319_3.patch
___
Python tracker
<http://bugs.python.org/issue12319>
___
___
Python-bug
Demian Brecht added the comment:
Thanks for the review Martin.
> However I understand Rolf specifically wanted chunked encoding to work with
> the existing urlopen() framework, at least after constructing a separate
> opener object. I think that should be practical with the
Demian Brecht added the comment:
I'm also +1 to handling this generically and agree that a well thought out and
researched proposal would be required.
I did mention in #18228 (http://bugs.python.org/issue18828#msg238363) that I
think that a short term solution to this problem could
Demian Brecht added the comment:
> it would be better to consolidate the three adjacent versionchanged entries
> into one
I created the three versionchanged items because there's no visual distinction
between the second and third lines and the rest of the doc tests in the
rend
New submission from Demian Brecht:
This came up during #2211, where a multiline versionchanged entry was
suggested. Currently, there is no visual distinction between any but the first
line of the description and the rest of the body of the docs. The attached
patch adds a consistent level of
Demian Brecht added the comment:
FWIW, I created #23778 to address the indentation issue.
--
___
Python tracker
<http://bugs.python.org/issue2211>
___
___
Pytho
Demian Brecht added the comment:
Problem (pretty much) solved. Nested unordered lists are supported. I've
updated the versionchanged information to use the list.
--
Added file:
http://bugs.python.org/file38690/http_cookies_morsel_deprecated_set_2.
Demian Brecht added the comment:
I noted in #2211 that nested lists are supported by Sphinx, so that solves that
specific issue. Perhaps it /may/ still be useful to have this though in order
to support multiple paragraphs for more detailed change descriptions when
needed? That said, I'
Demian Brecht added the comment:
Sounds good to me.
--
___
Python tracker
<http://bugs.python.org/issue23778>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Updated patch should address review comments. I did run with David's suggestion
as I also noticed that my initial assessment was wrong (thanks for the
note/review Berker).
--
Added file:
http://bugs.python.org/file
Demian Brecht added the comment:
As I understand it, the change should also be applied to security releases
as the regression manifested by a security related patch being applied.
That said, there may be some debate as there apparently isn't much (if
anything) in the way of precedence
Demian Brecht added the comment:
> The current behaviour when no scheme is present is fairly sensible to me and
> should not be changed to do string concatenation nor raise an exception
Agreed. Defaulting to relative behaviour makes sense as I imagine that'll be
the general use
Demian Brecht added the comment:
Thanks for following up on this David. The changes you've made all look good to
me.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23360>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38772/issue12319_4.patch
___
Python tracker
<http://bugs.python.org/issue12319>
___
___
Python-bug
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
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
&l
Demian Brecht added the comment:
Set as closed, assuming there's no reason to keep this issue open.
--
status: open -> closed
___
Python tracker
<http://bugs.python.or
301 - 400 of 434 matches
Mail list logo
