Changes by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<http://bugs.python.org/issue17229>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
> LGTM.
+1
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23418>
___
___
Python-bugs-list mai
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23440>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23410>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 wha
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
Changes by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<http://bugs.python.org/issue9698>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<http://bugs.python.org/issue23448>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issue23004>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<http://bugs.python.org/issue22197>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issue23043>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<http://bugs.python.org/issue21557>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<http://bugs.python.org/issue14414>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<http://bugs.python.org/issue22946>
___
___
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:
Changes by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<http://bugs.python.org/issue8843>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<http://bugs.python.org/issue12849>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<http://bugs.python.org/issue17908>
___
___
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:
Changes by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<http://bugs.python.org/issue12455>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
> If we leave it as it is, it would be good to add comment in the source code
> explaining this decision.
I think that __all__ should be left as-is for the time being. Adding
some comments around that decision makes sense to me to avoid any future
con
Demian Brecht added the comment:
I've attached a patch with fixes for both cases and the tests added by
Berker. Thanks guys.
--
Added file: http://bugs.python.org/file38122/issue23442_1.patch
___
Python tracker
<http://bugs.python.org/is
Demian Brecht added the comment:
Thanks for the test Berker, I'll put a patch together with the changes
later this afternoon.
On 2015-02-12 2:27 PM, Berker Peksag wrote:
>
> Berker Peksag added the comment:
>
> He
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue9698>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
The attached patch fixes the name
--
keywords: +patch
Added file: http://bugs.python.org/file38112/issue23442.patch
___
Python tracker
<http://bugs.python.org/issue23
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue10486>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
The only real question I have is: why? As far as I'm aware, these are
implementation details of the http.client module (there's even a comment in
HTTPMessage that it might make sense to move the class altogether).
As far as the constants go, they
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23439>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23448>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Thanks for the catch Martin, the field should indeed be updated to be
plural. I'll try to get a patch for this later today unless someone else
beats me to it
--
___
Python tracker
<http://bugs.python.org/is
Demian Brecht added the comment:
> Thanks for helping with this Demian.
No worries. This textual white boarding exercise has also been greatly
valuable in getting my own head wrapped around various low frequency
socket level errors that can be encountered when using the client. The
downside
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23434>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
@Mark: Sure, but not super high priority. Thanks for pointing it out.
--
___
Python tracker
<http://bugs.python.org/issue2
Demian Brecht added the comment:
My apologies for the delay, but I've now reviewed the proposed patch. With a
fresh outlook after taking a bit of time off, I'm not sure anymore that this is
the best way of going about solving this problem. The main reason being that we
now have
Demian Brecht added the comment:
I’ve reverted the patch to use the old format. The main reason being that plain
ints can still be used in most cases as values for code, in which case logging
will be inconsistent with cases using the enum.
--
Added file: http://bugs.python.org
Demian Brecht added the comment:
Thanks for the catch Martin, it definitely wasn't intended. I've added a patch
to fix the issue and add the extra description as suggested by Ethan.
--
Added file: http://bugs.python.org/file38068/issue21793_lo
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(),
Demian Brecht added the comment:
Updated patch based on review.
--
Added file: http://bugs.python.org/file37915/list_content_length_1.patch
___
Python tracker
<http://bugs.python.org/issue23
Changes by Demian Brecht :
--
components: +Library (Lib)
type: -> behavior
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue23350>
___
_
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
Demian Brecht added the comment:
Digging into this more, I've opened up a can of worms that will result in
http.client not looking nearly at all like http.client. I'll work this into
httplib3 and will open this conversation back up if it gets any traction.
--
resolution: -
Demian Brecht added the comment:
Ping for review/commit.
--
___
Python tracker
<http://bugs.python.org/issue22931>
___
___
Python-bugs-list mailing list
Unsub
Demian Brecht added the comment:
On 2015-01-28 7:41 AM, R. David Murray wrote:
> Although they are private interfaces we may decide we need a deprecation
> release before dropping them. Sometimes what we do in cases like this is go
> ahead and make the changes, but also provid
Demian Brecht added the comment:
New patch removes unrelated changes.
--
Added file: http://bugs.python.org/file37892/issue13128_3.patch
___
Python tracker
<http://bugs.python.org/issue13
Demian Brecht added the comment:
On 2015-01-27 7:34 PM, R. David Murray wrote:
> Quantifying "largely" will be important.
Understandably. In terms of the public API, all changes should be purely
additive and 100% backwards compatible. "largely" is referring to some
of t
Changes by Demian Brecht :
Added file: http://bugs.python.org/file37887/http_proto_1.patch
___
Python tracker
<http://bugs.python.org/issue23334>
___
___
Python-bug
Demian Brecht added the comment:
Attaching a file /with/ http.proto this time.
--
___
Python tracker
<http://bugs.python.org/issue23334>
___
___
Python-bugs-list m
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
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:
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
Demian Brecht added the comment:
Ping.
--
___
Python tracker
<http://bugs.python.org/issue13128>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
> 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 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:
> @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 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:
Other than Berker's comments, LGTM.
--
___
Python tracker
<http://bugs.python.org/issue23300>
___
___
Python-bugs-list m
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:
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:
@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
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
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
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
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:
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:
> 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:
No worries, thanks for taking care of merging it Berker.
--
___
Python tracker
<http://bugs.python.org/issue20898>
___
___
Pytho
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:
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
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:
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:
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:
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:
Ping. Would be nice to get this change in before 3.5.0a1.
--
___
Python tracker
<http://bugs.python.org/issue20898>
___
___
Pytho
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue8450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23166>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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:
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
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:
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
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:
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:
@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:
Ping
--
___
Python tracker
<http://bugs.python.org/issue22992>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
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:
> 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:
@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:
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:
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 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:
> 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:
> 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:
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:
+ 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
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:
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
201 - 300 of 434 matches
Mail list logo
