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:
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
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:
> 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
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:
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:
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:
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:
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:
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:
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:
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:
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:
> 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:
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:
> 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
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:
+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
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:
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:
Bump (again) for hopeful merge.
--
___
Python tracker
<http://bugs.python.org/issue21793>
___
___
Python-bugs-list mailin
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
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:
After discussion in Rietveld, the patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue21557>
___
___
Pytho
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:
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:
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
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:
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
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:
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:
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:
Left a comment in Rietveld.
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue21557>
___
___
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:
Thanks Serhiy, new patch addresses your comments.
--
___
Python tracker
<http://bugs.python.org/issue22095>
___
___
Python-bug
Changes by Demian Brecht :
Added file: http://bugs.python.org/file37309/issue22095_1.patch
___
Python tracker
<http://bugs.python.org/issue22095>
___
___
Python-bug
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22931>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Heh, I'd finally gotten a few minutes to address the comments... And it's
already taken care of ;) Thanks Senthil.
--
___
Python tracker
<http://bugs.python.o
Demian Brecht added the comment:
Antoine: On (finally) getting back to this and re-reading your test case, the
current behaviour is incorrect and is corrected by the patch. I've added a few
more test cases to ensure trailing slashes are handled correctly.
--
Added file:
Demian Brecht added the comment:
I'll try to get some time this week to extend the various test cases, thanks
for pointing that out Antoine.
I also found that, other than the few RFC-specific blocks in the link that Nick
added in the other ticket, not only were they questionable (non-HT
Changes by Demian Brecht :
--
keywords: +patch
Added file: http://bugs.python.org/file36479/issue22278.patch
___
Python tracker
<http://bugs.python.org/issue22
New submission from Demian Brecht:
Reported by Stefan Behnel in issue22118:
I'm now getting duplicated slashes in URLs, e.g.:
https://new//foo.html
http://my.little.server/url//logo.gif
In both cases, the base URL that gets joined with the postfix had a trailing
slash, e.g.
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22231>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22233>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22234>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Demian Brecht:
This is a proposal for adding SQLite support to http.cookiejar. I've been
working on an implementation for MozillaSQLiteCookieJar and
GoogleSQLiteCookieJar (initial patch will likely only include Mozilla) but
wanted to make sure that the addition has b
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22197>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Thanks Mike, it's always nice to get positive feedback :)
--
___
Python tracker
<http://bugs.python.org/issue22118>
___
___
Demian Brecht added the comment:
Uploaded new patch. Removed support for RFC1808-specific behaviour. Extracted
non-compliant tests into comment blocks indicating the behaviour is no longer
supported.
--
Added file: http://bugs.python.org/file36347/issue22118_2.patch
Demian Brecht added the comment:
If you can upload a patch (including tests) conforming to Rietveld's
requirements, I'm sure it would help in getting a review done.
--
___
Python tracker
<http://bugs.python.o
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue19494>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
FWIW, I think that it would be ever so slightly preferable to maintain support
for the old behaviour but perhaps add a deprecation note in the docs. It's a
little difficult to tell how much of an impact this change will have to
existing code. Mainta
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22165>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Bump for review
--
___
Python tracker
<http://bugs.python.org/issue22095>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22147>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Update based on review comments, added legacy support, fixed the tests up.
--
Added file: http://bugs.python.org/file36296/issue22118_1.patch
___
Python tracker
<http://bugs.python.org/issue22
Demian Brecht added the comment:
Here's an initial patch with a fix that passes all the test cases other than
the ones that are incorrect based on examples and pseudocode in RFC 3986. I
haven't checked obsoleted RFCs yet to ensure consistency, but will do so when I
get a chan
Demian Brecht added the comment:
I've only had a couple minutes to look into this so far, but the bug does
indeed seem to be valid across all versions. In fact, the line "# XXX The stuff
below is bogus in various ways..." in urljoin tipped me off to something
potentia
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22118>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue15082>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
No problem, happy you were able to get things sorted. Feel free to close this
issue as I've opened #22095 to address the host port header issue.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Demian Brecht :
--
keywords: +patch
Added file: http://bugs.python.org/file36140/issue22095.patch
___
Python tracker
<http://bugs.python.org/issue22
New submission from Demian Brecht:
Creating this bug for clarity, but was encountered while investigating 22041
(now set as not a bug).
When using set_tunnel with default port, the port value in the host header is
set to "None":
"send: b'POST [PATH] HTTP/1.1\r\nHost: [
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue12319>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Sorry Alejandro, I should have clarified: The attached patch is for dev, so the
failure you're seeing when attempting to apply the patch against 3.3 is
expected. It effectively does the same thing as explicitly setting the port as
you have already atte
Demian Brecht added the comment:
To add a little more detail, from what I gather, CONNECT support may be
unsupported or limited (i.e. only allowing SSL connections) on various proxy
servers. If the code snippet in my previous post solves your issue, then I
would assume that to be the case
Demian Brecht added the comment:
Attached a new patch with with a simple test.
--
Added file: http://bugs.python.org/file36079/issue22041_1.patch
___
Python tracker
<http://bugs.python.org/issue22
Demian Brecht added the comment:
I've attached a patch that solves the issue I encountered. It would be great if
you could confirm whether or not it also resolves the issue as reported.
--
keywords: +patch
Added file: http://bugs.python.org/file36066/issue22041.
Demian Brecht added the comment:
Ignore my previous note. Digging into this a little more, I think I've possibly
found the underlying issue:
If the port is not specified in set_tunnel (as in your example), the buffer
sent over the wire looks like
"send: b'POST [PATH] HTTP/1.1
Demian Brecht added the comment:
Hi Alejandro,
I've spent a little time looking into this. I haven't been able to reproduce
what you're seeing on Windows exactly, but I've encountered other issues along
the same path using a local squid instance (localhost:4242):
from h
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue14044>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue3566>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue15267>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Left a couple comments on Rietveld
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue21850>
___
___
Pytho
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue22041>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue14301>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Attached a simple fix to the problem as written, matching logging method of
HTTPResponse.begin().
--
nosy: +demian.brecht
Added file: http://bugs.python.org/file36018/issue13128.patch
___
Python tracker
<h
Demian Brecht added the comment:
Being this is tagged for 3.5, I've refactored status codes as part of #21793.
Should that be accepted and merged, that will also clear up this issue.
--
___
Python tracker
<http://bugs.python.org/is
Demian Brecht added the comment:
Removed draft status code, removed S from VARIANTS_
--
Added file: http://bugs.python.org/file36012/issue21793_2.patch
___
Python tracker
<http://bugs.python.org/issue21
Demian Brecht added the comment:
Of /course/ a patch always helps :)
--
___
Python tracker
<http://bugs.python.org/issue14414>
___
___
Python-bugs-list mailin
Changes by Demian Brecht :
--
nosy: +dbrecht
___
Python tracker
<http://bugs.python.org/issue14414>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
FWIW, here's my take on this:
RFC 2617 (3.2.2.5) states: This may be "*", an "absoluteURL" or an "abs_path"
as specified in section 5.1.2 of [2], but it MUST agree with the Request-URI.
Note: It must AGREE.
RFC 3986 (6.2.3)
Changes by Demian Brecht :
--
nosy: +dbrecht
___
Python tracker
<http://bugs.python.org/issue8843>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Bump for a follow-up review or merge
--
___
Python tracker
<http://bugs.python.org/issue21793>
___
___
Python-bugs-list mailin
Changes by Demian Brecht :
--
nosy: +dbrecht
___
Python tracker
<http://bugs.python.org/issue17229>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +dbrecht
___
Python tracker
<http://bugs.python.org/issue21818>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
I very well could be missing something here (and, admittedly, my OS knowledge
is rusty at best), but for the most part, page sizes are 4096, except for
SPARC, which is 8192.
> So your page double the number of calls to read(), right?
No. read() is cal
Demian Brecht added the comment:
Updated patch with silly missed doc update.
--
Added file: http://bugs.python.org/file35711/issue21793_1.patch
___
Python tracker
<http://bugs.python.org/issue21
Demian Brecht added the comment:
New patch attached addressing review comments.
--
Added file: http://bugs.python.org/file35708/issue21793.patch
___
Python tracker
<http://bugs.python.org/issue21
Demian Brecht added the comment:
Updated to mmap.PAGESIZE, which seems to be available on all systems.
--
Added file: http://bugs.python.org/file35707/issue21790.patch
___
Python tracker
<http://bugs.python.org/issue21
Demian Brecht added the comment:
The problem here as far as I can tell is that the underlying file object
(addinfourl) blocks while waiting for a full response from the server. As
detailed in section 8.1 of RFC 2616, requests and responses can be pipelined,
meaning requests can be sent while
Demian Brecht added the comment:
Attached new patch with changes from review and a stab at an update to the docs.
--
Added file: http://bugs.python.org/file35680/refactor_http_status_codes_1.patch
___
Python tracker
<http://bugs.python.
New submission from Demian Brecht:
This patch is a follow up to an out of scope comment made by R. David Murray in
#20898 (http://bugs.python.org/issue20898#msg213771).
In a nutshell, there is some redundancy between http.client and http.server
insofar as the definition of http status code
New submission from Demian Brecht:
When sending data, the blocksize is currently hardcoded to 8192. It should
likely be set to the value of resource.getpagesize().
--
components: Library (Lib)
files: set_blocksize_to_getpagesize.diff
keywords: patch
messages: 220839
nosy: dbrecht
Demian Brecht added the comment:
I have a few questions about this one:
1. Why is print used to begin with? Surely this should use debug logging. Using
print, you lose the benefits of logging: Timestamps, if used in the configured
logger, can be invaluable to match up against logs generated
Changes by Demian Brecht :
--
nosy: +dbrecht
___
Python tracker
<http://bugs.python.org/issue19917>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +dbrecht
___
Python tracker
<http://bugs.python.org/issue3430>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
I actually made a similar change for issue #15025 earlier today. One of the two
should likely be closed as a dupe.
--
nosy: +dbrecht
___
Python tracker
<http://bugs.python.org/issue20
Changes by Demian Brecht :
Added file: http://bugs.python.org/file35665/issue15025_b.diff
___
Python tracker
<http://bugs.python.org/issue15025>
___
___
Python-bugs-list m
Demian Brecht added the comment:
Indeed the WEBDAV codes were missing across the board. I've added a couple
patches: One (_a) that just adds the missing constants, and another (_b) that
changes how they're defined altogether. The advantage of the second is that
there is much less
301 - 400 of 434 matches
Mail list logo
