Demian Brecht added the comment:
I was able to repro this with Terry's steps on latest hg update. I've taken
Scott's patch and updated it to diff from source root (his was pointing to
/usr/lib) against the latest. The patch fixes the issue and I also can't see
any negativ
Demian Brecht added the comment:
That was silly of me. What I /meant/ to say was that, for this specific report,
it's functioning as expected. However, the logic in LWPCookieJar isn't entirely
correct. As noted in the comments from libwww-perl, the reported URL is in
fact, an i
Demian Brecht added the comment:
(Note: Additional context can be found here: http://bugs.python.org/issue16942,
which seems to be a dupe of this report)
I haven't had any feedback to my proposal on python-ideas about the removal of
LWPCookieJar and MozillaCookieJar and the introducti
Demian Brecht added the comment:
@Terry: I don't think that the name change is unnecessary as the patch changes
the semantics of the the LWP and Mozilla Cookie classes. In the patch, they no
longer /are/ a subclass of a CookieJar, but they take a CookieJar object and
implemen
Demian Brecht added the comment:
@B. Kyven: What are you trying to achieve?
LWP is intended to be used with libwww-perl libary, which is not known to be
compatible with any browsers (not sure whether or not this has any bearing on
what you're doing).
Really, IMHO, this entire module
Demian Brecht added the comment:
No worries.
The change is not backwards incompatible. test_urllib2 test pass without any
modification (I'm getting a segfault in test_heapq atm so can't run the full
suite). I've simply moved the side effects cause by __init__ to a setter so
th
Demian Brecht added the comment:
Based on your and Andrew's comment in issue #16464 (new behaviour so it should
only apply to 3.4), I agree that this should be a 3.4-only change.
--
___
Python tracker
<http://bugs.python.org/is
Demian Brecht added the comment:
Patch updated (acks update, fixed order) per Terry's instructions on
core-mentorship.
--
Added file: http://bugs.python.org/file29589/request_17272.1.patch
___
Python tracker
<http://bugs.python.org/is
Demian Brecht added the comment:
Just noticed there was a typo in the link in my previous post. It should be
directing to issue# 16901.
--
___
Python tracker
<http://bugs.python.org/issue16
Demian Brecht added the comment:
As suggested by Senthil, I've broken this up into two patches: One that
implements this reusable Request (this one) and one that implements the new
(consistent) behaviour, in having full_url return the fragment.
I will also add a bug/patch requestin
Changes by Demian Brecht :
Added file:
http://bugs.python.org/file29995/request_17272.2.full_url_w_fragment.patch
___
Python tracker
<http://bugs.python.org/issue17
Demian Brecht added the comment:
Issue 8280 reports the error by way of urlopen(). In light of that, would it
not make more sense to have the *Opener be responsible for determining which
parts of the url should be used?
i.e. request.py, line ~1255:
r.url = req.get_full_url()
might instead
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22931>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
Added file: http://bugs.python.org/file37309/issue22095_1.patch
___
Python tracker
<http://bugs.python.org/issue22095>
___
___
Python-bug
Demian Brecht added the comment:
Thanks Serhiy, new patch addresses your comments.
--
___
Python tracker
<http://bugs.python.org/issue22095>
___
___
Python-bug
Demian Brecht added the comment:
There could be some history behind this that I'm unaware of that I'm not
familiar with.
>From what I can tell, this issue is simply due to the "[" character not being
>in _LegalCharsPatt (http/cookies.py). _LegalCharsPatt actuall
Demian Brecht added the comment:
Left a comment in Rietveld.
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue21557>
___
___
Python-bug
Demian Brecht added the comment:
It's generally better to keep everything in one issue in order to preserve
history and avoid confusion as you've now found :). I'd suggest closing this
one and adding the patch to the initial report. Keeping history intact is
importan
Demian Brecht added the comment:
Err, sorry, I entirely misunderstood the problem. The invalid characters are
correct ([ = 5B, which indeed is illegal, I wasn't paying close enough
attention to the hex values in the ABNF). It's the fact that the valid
key/value pairs after the inval
Demian Brecht added the comment:
Now I've confused myself and my first impression was correct. For some reason,
my brain was thinking "%x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E" was the
exclusion list for some reason (which is obviously horribly wrong).
So my first observat
Demian Brecht added the comment:
Attached patch to fix the issue as reported.
Something interesting that came out of this though is that due to the regex
expression, if there's an invalid character in one of the cookie-octets, the
rest of the cookie is ignored. I would assume that it s
New submission from Demian Brecht:
As found in #22931, if an invalid cookie value is found while parsing, the rest
of the cookie is silently ignored. The expected behavior is undefined in RFC
6265, but does state that if unexpected values are encountered that user agents
MAY ignore an entire
Demian Brecht added the comment:
I do think it should be a little more permissive when parsing cookies. I've
created #22983 to address that as to not conflate this issue, which the
attached patch does address.
--
___
Python tracker
Demian Brecht added the comment:
Sure, but this is in regards to the initial matching, not the parsing. Because
the pattern expects RFC conformity, in this cookie string:
Cookie: a=b; c=[; d=r; f=h
The only matching parts will be:
Cookie: a=b;
The rest will be discarded. What I'm prop
Demian Brecht added the comment:
Sorry, bad example. Replace "[" in the previous example with any actually
invalid character.
--
___
Python tracker
<http://bugs.python.o
Demian Brecht added the comment:
After discussion in Rietveld, the patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue21557>
___
___
Pytho
New submission from Demian Brecht:
Coming out of a recent thread in python-dev, it was mentioned that adding a git
developer's guide to mercurial may be beneficial to help lower the initial
barrier of entry for prospective contributors
(https://mail.python.org/pipermail/python-dev
Demian Brecht added the comment:
Thanks for the comments, will try to have an updated patch today.
> Trying to learn usual hg workflows might also be easier than trying to use a
> git-like workflow on mercurial, so you could suggest considering them too (I
> don't remember if we
Demian Brecht added the comment:
Bump (again) for hopeful merge.
--
___
Python tracker
<http://bugs.python.org/issue21793>
___
___
Python-bugs-list mailin
Demian Brecht added the comment:
I believe most points should be addressed in the updated patch. Below are
responses to other comments (those not included have resulted in changes in the
patch).
@Ezio:
> 4) it should be possible to use evolve instead of bookmarks, but evolve is
> cur
Demian Brecht added the comment:
Updated patch addressing review comments. Thanks for the review.
--
Added file: http://bugs.python.org/file37368/issue21793_3.patch
___
Python tracker
<http://bugs.python.org/issue21
Demian Brecht added the comment:
+1 to the addition of a test. Also, I know it's only related, but it might be
nice to also have this fixed in http_error_default:
https://hg.python.org/cpython/file/021c1df36910/Lib/urllib/request.py#l2003.
--
nosy: +demian.b
Changes by Demian Brecht :
Added file: http://bugs.python.org/file37370/issue21793_4.patch
___
Python tracker
<http://bugs.python.org/issue21793>
___
___
Python-bug
Demian Brecht added the comment:
> Contributors may need to update their repos before this step. It would be
> good to add a note about "git pull --rebase".
Working through this flow actually exposed a blocking issue as far as this
guide goes. As I understand it, because
Demian Brecht added the comment:
One option would be to increase LimitRequestFieldSize in Apache, but that
really is only a stopgap solution as that limit will be hit again as one's
local repo grows over time. It really would be nice to allow read only access
via SSH, which isn't a
Demian Brecht added the comment:
> Did you actually hit this issue with hg.python.org?
Yes I did, with only one additional head:
https://gist.github.com/demianbrecht/f525cceda8a0c99794ae. This would also lead
me to believe that the public at large will also start hitting this with
Demian Brecht added the comment:
After some further investigation, this seems to be what's happening. Note: this
is based on a small amount of research and hasn't been validated by any
mercurial devs, so it might be missing key pieces: In cases where a local
topological head is un
Demian Brecht added the comment:
The issue and solution was confirmed on IRC in #mercurial by mpm (Matt
Mackall). According to him, there is also no easy way to change this behaviour
from the client. The problem isn't /really/ a Mercurial issue, but an issue
with web server specific def
Demian Brecht added the comment:
I've added a section about rebasing and removed the comment about merging. Of
course, I'm assuming that the config changes can be made to Apache to allow for
this workflow.
--
Added file: http://bugs.python.org/file37412/issue229
Demian Brecht added the comment:
Coming back to this, it's likely a bad idea as an addition to the standard
library as an update may be required out of band with scheduled deployments
should schemas and such change. This is best developed as an external module.
Closing.
--
s
Demian Brecht added the comment:
Thanks for the ping Serhiy, indeed the review notification email was sitting in
spam. New patch addressing review comments as well as rectifying my own
silliness.
--
Added file: http://bugs.python.org/file37419/issue22095_2.patch
Demian Brecht added the comment:
Self review/update: removed two errant breakpoints and updated the what's new
section (missed in my previous patch).
--
Added file: http://bugs.python.org/file37420/issue21793_5.patch
___
Python tracker
Demian Brecht added the comment:
The issue was actually HAProxy rather than Apache (I had misread a line in the
documentation so my understanding of Apache header limitations was incorrect).
This was fixed by Donald today. If there are no objections, this should be good
to merge now
Demian Brecht added the comment:
Updated patch addressing further reviews
--
Added file: http://bugs.python.org/file37434/issue21793_6.patch
___
Python tracker
<http://bugs.python.org/issue21
Demian Brecht added the comment:
Thanks for the patch Aaron. Unfortunately this doesn't quite fix the issue.
There are two problems with the patch:
If a bytes object is passed into mock_open, I'd expect a bytes object in the
output. In your patch, not only is this not the case (the
Demian Brecht added the comment:
> There are two problems with the patch
That was intended to be removed after I changed the wording :P
--
___
Python tracker
<http://bugs.python.org/issu
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23043>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Thanks for the update, but this doesn't quite work either as you're assuming
utf-8 (which is what .encode() and .decode() default to). For example, when
using latin-1:
>>> m = mock_open(read_data= b'\xc6')
>>> with
Demian Brecht added the comment:
Thanks again for the update Aaron, I've left a couple small comments in
Rietveld. Other than those, the patch looks good to me. Thanks for the
contribution!
--
___
Python tracker
<http://bugs.python.org/is
Demian Brecht added the comment:
I'm a -1 to adding the timeout parameter to the ServerProxy implementation for
pretty much the same reasons Jeff mentioned, but mainly because of the
ambiguity that is introduced between the timeout and transport parameters (who
should win in the case
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22928>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
+ loewis as he's listed as the xmlrpc expert
If you're worried about the number of lines, turn the function into a lambda:
proxy = ServerProxy('http://example.com/gateway/', transport=Transport(
connection_factory=lambda h: HTTPC
Demian Brecht added the comment:
Thanks for the updated patch, looks good to me. If you haven't already read it,
the patch workflow is here: https://docs.python.org/devguide/patch.html and is
the only workflow currently available.
--
___
P
Demian Brecht added the comment:
> socket.setdefaulttimeout([timeout]) -- it is bad practice
I'm not really arguing this. It solves the problem, but definitely not in the
best of ways. My point in referencing setdefaulttimeout is that if /all/ you
care about is the timeout an
Demian Brecht added the comment:
> in GNU/Linux "system timeout has been reached" -- means that system timeout
> will *never* reached.
That's quite likely because the system limits may be very large. For example,
on my OSX box:
--- ~ » sysctl
Demian Brecht added the comment:
I think we've started to venture into system-level territory that the standard
library itself shouldn't have to account for. If TCP on systems are configured
by default to allow for infinite timeouts, then it should likely be an issue
for those
Demian Brecht added the comment:
On another note, running a simple test with against a non-routable IP yields
that OSX's default timeout is 75 seconds and not 7500 seconds as the developer
docs lead me to believe.
--
___
Python tracker
Demian Brecht added the comment:
I've attached a test-less patch with my suggested approach. If there's no
opposition to this change, I'll put some work into getting tests done for it as
well.
--
Added file: http://bugs.python.org/file37481/i
Demian Brecht added the comment:
@Julien.Palard: There's a subtle difference between your test and the issue as
written. Your test lives within a module and therefore executes testmodule (see
https://hg.python.org/cpython/file/9f60d024e586/Lib/doctest.py#l1819) whereas
the issue reported
Demian Brecht added the comment:
> it's been resolved in 3.5
Sorry, that statement can be a little misleading, possibly indicating that
something may have changed in the doctest globals handling. It was resolved in
3.5 because print is no longer a statement so this ambiguous b
Demian Brecht added the comment:
The patch in #21793 has been merged, resolving this issue as well. This should
now be closed.
--
___
Python tracker
<http://bugs.python.org/issue20
Demian Brecht added the comment:
A few more comments were left in Rietveld for you, likely hidden by spam
filters.
--
___
Python tracker
<http://bugs.python.org/issue23
Demian Brecht added the comment:
Ping
--
___
Python tracker
<http://bugs.python.org/issue22992>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
@Berker: Good point, although I think that the status code table in
http.client.rst should be merged with the one in http.rst as to avoid
redundancy (newly added status codes should also have links added). The table
in http.client.rst should likely be replaced
Demian Brecht added the comment:
A few notes:
1. Unicode hosts are not automatically IDNA-encoded (which they /could/ be
rather than relying on the programmer to be aware of this), but this really has
no bearing on this specific issue
2. Unicode paths are not automatically IRI-encoded (see
Demian Brecht added the comment:
utf-8 encoding is only one step in IRI encoding. Correct IRI encoding is non
trivial and doesn't fall into the support policy for 2.7 (bug/security fixes).
I think that the best that can be done for 2.7 is to enhance the documentation
around HTTPConne
Demian Brecht added the comment:
The attached patch is a rework of the http.HTTPStatus docs to include links to
the RFCs. While working through this, I noticed that I may have been a little
overzealous in inclusion of some of the status codes. Some non-standard codes
have been deprecated or
Changes by Demian Brecht :
Removed file: http://bugs.python.org/file37481/issue14134.patch
___
Python tracker
<http://bugs.python.org/issue14134>
___
___
Python-bug
Demian Brecht added the comment:
I withdraw my patch as (I just discovered), it is already possible to effect
changes to the underlying connection. What /should/ be done is:
transport = Transport()
con = transport.make_connection([host])
con.timeout = 2
proxy = ServerProxy([url], transport
Demian Brecht added the comment:
Just happened to come across this now. Updated patch with test.
--
Added file: http://bugs.python.org/file37621/issue13128_2.patch
___
Python tracker
<http://bugs.python.org/issue13
Demian Brecht added the comment:
Thanks for the response Brett and no worries, the delay is totally
understandable.
--
___
Python tracker
<http://bugs.python.org/issue22
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23166>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue8450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Ping. Would be nice to get this change in before 3.5.0a1.
--
___
Python tracker
<http://bugs.python.org/issue20898>
___
___
Pytho
Demian Brecht added the comment:
This should likely be closed as a duplicate of #3566, which has additional
detail.
--
___
Python tracker
<http://bugs.python.org/issue8
Demian Brecht added the comment:
Trying to reproduce this on my own in 3.5, 2.7 and 2.5 yields a
ConnectionResetError (ECONNRESET), which seems to be correct. That said, this
could be due to varying TCP implementations on the server so might still be
valid. It could also be due to an older
Demian Brecht added the comment:
Hi Martin,
Thanks for the example code. I'm not sure whether or not this was your
intention, but your example demonstrates a misbehaving client, one that seems
to expect a persistent connection from a non-persistent server. TCPServer will
only serve a s
Demian Brecht added the comment:
> I'm not sure whether or not this was your intention, but your example
> demonstrates a misbehaving client, one that seems to expect a persistent
> connection from a non-persistent server. TCPServer will only serve a single
> request and
Demian Brecht added the comment:
Sorry Martin, I should really not dig into issues like this first thing in the
morning ;)
My concern about the proposed change isn't whether or not it isn't valid HTTP
behaviour, it is. My concern (albeit a small one) is that the change implies an
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23255>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
No worries, thanks for taking care of merging it Berker.
--
___
Python tracker
<http://bugs.python.org/issue20898>
___
___
Pytho
Demian Brecht added the comment:
> Calling self.wfile.write(b"") should be equivalent to not calling write() at
> all, as far as I understand.
Right (or at least, as I understand it as well).
Really, this boils down to a philosophical debate: Should the standard libr
Demian Brecht added the comment:
TL;DR: Because HTTP is an application-level protocol, it's nearly impossible to
gauge how a server will behave given a set of conditions. Because of that, any
time that assumptions can be avoided, they should be.
@R. David Murray:
> That is
Demian Brecht added the comment:
Now I think I'd like to take my foot out of my mouth.
Previous quick experiments that I had done were at the socket level,
circumventing some of the logic in the HTTPResponse, mainly the calls to
readline() rather than simple socket.recv().
I've
Demian Brecht added the comment:
(Admittedly, I may also have been doing something entirely invalid in previous
experiments as well)
--
___
Python tracker
<http://bugs.python.org/issue3
New submission from Demian Brecht:
There are a couple of small issues with the determination of whether or not a
request can fit in a single TCP/IP packet in http.client.
1. The MSS is hardcoded
2. The TCP data size is calculated as only the message body. This is incorrect
as the size of the
Changes by Demian Brecht :
--
components: +Library (Lib)
keywords: +patch
versions: +Python 3.5
Added file: http://bugs.python.org/file37822/issue23302.patch
___
Python tracker
<http://bugs.python.org/issue23
Demian Brecht added the comment:
@Senthil: If you're fixing this today, can you also correct the typo here:
https://hg.python.org/cpython/rev/568041fd8090/#l1.27 (s/HTML/HTTP)? Just
caught my eye going through the review that Mark linked.
--
nosy: +demian.b
Demian Brecht added the comment:
I'm not opposed to that either. The only downside really (at least as far as
I'm aware) is the potential substantial influx of packets should an iterable
comprised of small chunks of data be passed in as the body, although I would
consider that quite
Demian Brecht added the comment:
I've attached a new patch disabling Nagle by default, but doing so in connect()
as to allow users to override it if they really want to. I've also removed the
use of mss in HTTPConnection. This is a backwards incompatible change in two
ways:
1. Re
Demian Brecht added the comment:
Other than Berker's comments, LGTM.
--
___
Python tracker
<http://bugs.python.org/issue23300>
___
___
Python-bugs-list m
Demian Brecht added the comment:
Thanks for the work! I'm not sure why the last patch doesn't appear on
Rietveld, so (unfortunately) here's the result of my review. I've only covered
functional aspects in this run at it:
+base_files = ['index.html', 'in
Demian Brecht added the comment:
> @demian: If you don't mind, could you please elaborate a bit more on
> `_resolve_path()` you mentioned in the review/comment?
Sure. In your patch, you have redirect_browser (or redirect if you
renamed it), which sounds like it's allowing fo
Demian Brecht added the comment:
Thanks for the patch Martin (as well as catching a couple issues that I'd run
into recently as well). I've left a couple comments up on Rietveld.
--
___
Python tracker
<http://bugs.python.
Demian Brecht added the comment:
> now I’m thinking that should be up to the higher level user
+1. A closed connection is a closed connection, whether it's persistent or not.
The higher level code should be responsible for the context, not the connectio
Demian Brecht added the comment:
Thanks for the extra effort on this to satisfy multiple people's opinions. It's
never an easy thing, especially when dealing with a decentralized group. My
following comments are largely based on the public API. I haven't done a full
review of t
Demian Brecht added the comment:
Ping.
--
___
Python tracker
<http://bugs.python.org/issue13128>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Sure, I should have some time later today to do so.
Should such changes not be made as they're encountered in order to clean
up the older code that isn't up to spec? Or should they only be made as
the code is modified?
On 2015-01-27 2:58 PM, Berker Pe
New submission from Demian Brecht:
This is an attempt to bring a little more sanity to the http.client module
through improvements to the architecture. The overarching intention of the
patch is to modularize the HTTP versions, providing the following benefits:
* Make each protocol easier to
Demian Brecht added the comment:
Note that this patch also depends on Antoine's TransformDict patch in #18986.
--
___
Python tracker
<http://bugs.python.org/is
101 - 200 of 434 matches
Mail list logo
