[issue24337] Implement `http.client.HTTPMessage.__repr__` to make debugging easier
Change by Demian Brecht : -- nosy: +demian.brecht ___ Python tracker <https://bugs.python.org/issue24337> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12144] cookielib.CookieJar.make_cookies fails for cookies with 'expires' set
Demian Brecht added the comment: @xtreak sure, can do. May not have time to do so today but should be able to do so over the next couple days. -- ___ Python tracker <https://bugs.python.org/issue12144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24177] Add https?_proxy support to http.client
Change by Demian Brecht : -- keywords: +patch, patch pull_requests: +11617, 11618 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue24177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24177] Add https?_proxy support to http.client
Change by Demian Brecht : -- keywords: +patch, patch, patch pull_requests: +11617, 11618, 11619 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue24177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24177] Add https?_proxy support to http.client
Change by Demian Brecht : -- keywords: +patch pull_requests: +11617 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue24177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3430] httplib.HTTPResponse documentations inconsistent
Change by Demian Brecht : -- nosy: -demian.brecht ___ Python tracker <https://bugs.python.org/issue3430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17251] LWPCookieJar load() set domain_specifed wrong
Change by Demian Brecht : -- nosy: -demian.brecht ___ Python tracker <https://bugs.python.org/issue17251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20911] urllib 'headers' is not a well defined data type
Demian Brecht added the comment:
>>> urlopen('https://example.com').info()
>>> urlopen('http://example.com').info()
>>> urlopen('ftp://speedtest.tele2.net').info()
>>> urlopen('file:///path/to/setup.py').info()
I've taken a look at the rest of the handlers in urllib.request and they all
build headers consistently with email.message_from_string().
Closing as out of date.
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue20911>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20911] urllib 'headers' is not a well defined data type
Demian Brecht added the comment: @R. David Murray Is this issue still valid? Running 3.6 it seems that http and ftp are consistent at any rate (http returns http.client.HTTPMessage and ftp returns email.message.Message). If it's still an issue, could you please elaborate? -- ___ Python tracker <https://bugs.python.org/issue20911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12707] Deprecate addinfourl getters
Change by Demian Brecht : -- nosy: +demian.brecht ___ Python tracker <https://bugs.python.org/issue12707> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20582] socket.getnameinfo() does not document flags
Demian Brecht added the comment: What if the docs for socket functions that took system-level flag parameters had links to relevant online man pages? I don't think a single entry at the top of the page would be optimal. I know that I tend to skip the preamble and just go directly to the function I'm interested in. I know that it's not a perfect solution because there's a good chance of those links going stale. I'm also relatively sure that we wouldn't want to have an exhaustive list. However, I think in this instance that /something/ would be better than nothing. Even if the link is stale or the target OS isn't included, it would give the reader a place to start, which is currently lacking. -- ___ Python tracker <https://bugs.python.org/issue20582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20582] socket.getnameinfo() does not document flags
Change by Demian Brecht : -- nosy: +demian.brecht ___ Python tracker <https://bugs.python.org/issue20582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily
Change by Demian Brecht : -- nosy: +demian.brecht ___ Python tracker <https://bugs.python.org/issue35292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33399] site.abs_paths should handle None __cached__ type
Change by Demian Brecht <demianbre...@gmail.com>: -- keywords: +patch pull_requests: +6369 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33399] site.abs_paths should handle None __cached__ type
New submission from Demian Brecht <demianbre...@gmail.com>: Echoing an email sent to python-list: I recently ran into an issue using the site package and I wanted to confirm that I'm not doing something wrong here before creating an issue: I have a need to `git subtree` modules into a Django project and then add the dependencies such that they're discoverable in code. I also need to have consistent behavior between `python setup.py (develop|install)` and `pip install -r requirements.txt` (the latter is used by Heroku for project installation). An example project that demonstrates the issue is here: https://github.com/demianbrecht/python-sitehooks-example. In the example, I've subtree'd requests into _vendor and forced site hooks to fire using `site.main()` in testme/settings.py: https://github.com/demianbrecht/python-sitehooks-example/commit/1b81e15c6f28bc80a4f984cffa78eb2ced80a320. Forcing the execution is not needed when the package is actually installed using setup.py, but is needed when using `pip install -r requirements.txt`. This works great when running within a virtualenv, but I get the following on system python: $ python3.6 ./manage.py test Traceback (most recent call last): File "./manage.py", line 22, in execute_from_command_line(sys.argv) File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line utility.execute() File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 308, in execute settings.INSTALLED_APPS File "/usr/local/lib/python3.6/site-packages/django/conf/__init__.py", line 56, in __getattr__ self._setup(name) File "/usr/local/lib/python3.6/site-packages/django/conf/__init__.py", line 41, in _setup self._wrapped = Settings(settings_module) File "/usr/local/lib/python3.6/site-packages/django/conf/__init__.py", line 110, in __init__ mod = importlib.import_module(self.SETTINGS_MODULE) File "/usr/local/lib/python3.6/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 978, in _gcd_import File "", line 961, in _find_and_load File "", line 950, in _find_and_load_unlocked File "", line 655, in _load_unlocked File "", line 678, in exec_module File "", line 205, in _call_with_frames_removed File "///testme/testme/settings.py", line 13, in site.main() File "/usr/local/lib/python3.6/site.py", line 525, in main abs_paths() File "/usr/local/lib/python3.6/site.py", line 110, in abs_paths m.__cached__ = os.path.abspath(m.__cached__) File "/usr/local/lib/python3.6/posixpath.py", line 369, in abspath path = os.fspath(path) TypeError: expected str, bytes or os.PathLike object, not NoneType Using venv and system comparisons for debugging doesn't help much as site.py is different in the two environments. Any insight into what may be going on here or what I'm doing wrong would be much appreciated. I realize that I could just muck with PYTHONPATH, but I thought this approach would be a little nicer as it's transparent to the user. Digging a little deeper, it seems that site.abs_paths fails when a module's __cached__ value is None. I haven't spent enough time digging into it to understand why this is valid behavior, hoping to get some insight from folks who have spent more time on it. -- components: Library (Lib) messages: 316008 nosy: demian.brecht priority: normal severity: normal status: open title: site.abs_paths should handle None __cached__ type versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26380] Add an http method enum
Demian Brecht added the comment: > BTW I think it is actually OPTIONS; see review comment. Well, don't I feel silly. Fixed. -- Added file: http://bugs.python.org/file41962/issue26380_2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26380] Add an http method enum
Demian Brecht added the comment: > I can see the advantage of using an enum over a plain string. But you only > get an error at run time, not compile time, if you misspell it. Sure, but at least you're giving static analysis utilities the chance to catch it up front. > And there is also the disadvantage of the extra boilerplate of importing > HTTPMessage. I guess that all depends on how you're importing your modules. If you just import "http", then there's no additional boilerplate. > So I don’t have a strong opinion either way. Do other libraries have a > similar enum? I haven't seen enums in other libraries, only constants. I figured that it might as well be consistent with HTTPStatus, although granted, HTTPStatus does a little more than the methods. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26380] Add an http method enum
Demian Brecht added the comment: > I don't have a firm opinion at this point -- can you give a few examples of > how this will help in code? It'll help solely with consistency across projects. Generally, using constants are generally favored over using hardcoded values. Mainly, it helps reduce typos. Some projects use literals, others use project-specific constants. It's something that I've found myself redefining over various projects, and I just though "why couldn't this be added to the standard library, given it's an attribute of the HTTP/1.1 RFC"? /Very/ minor, personal annoyance. The updated patch fixes the OPTION typo. -- Added file: http://bugs.python.org/file41960/issue26380_1.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26380] Add an http method enum
Demian Brecht added the comment: If nobody's opposed to the addition, I'll run through the unit tests and replace the hard coded strings. -- keywords: +patch Added file: http://bugs.python.org/file41947/issue26380.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26380] Add an http method enum
New submission from Demian Brecht: Super minor annoyance that I've had over multiple projects is seeing either hard coded strings being used (which is a bit of a no-no in terms of best practices) or each project defining its own set of constants for http methods. Why not just include a standard set in http as is done for status codes? -- components: Library (Lib) keywords: needs review messages: 260431 nosy: demian.brecht, r.david.murray priority: normal severity: normal status: open title: Add an http method enum versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24177] Add https?_proxy support to http.client
Demian Brecht added the comment: Yeah, agreed that it should be opt-in, at least until a major release. I've run into a couple cases where higher level libraries use http.client (or httplib) directly, but don't expose the client directly (not that they should anyways). Because of that, there are higher level libraries that simply /can't/ support http_proxy environment variable because they didn't use a higher level abstraction. Given http.client /does/ implement everything required to support this, I can't see it impacting the architecture in any negative way. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23377] HTTPResponse may drop buffer holding next response
Demian Brecht added the comment: Actually had a few free minutes so stuck a couple minor comments in Rietveld. Will have another go as soon as possible. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23377 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24363] httplib fails to handle semivalid HTTP headers
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24363 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12319] [http.client] HTTPConnection.request not support chunked Transfer-Encoding to send data
Demian Brecht added the comment: FWIW, I was intending to address the issues Rolf raised. Also, I agree that a patch shouldn't knowingly have negative knock-on effects to dependents. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24209] Allow IPv6 bind in http.server
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24255] Replace debuglevel-related logic with logging
New submission from Demian Brecht: Far too many times have I wished that changing the logging output in http.client was controllable through logging configuration rather than code changes modifying a connection's debuglevel. It would be nice if the http package was brought up to date and had debuglevel-related code replaced with logging and sane logging was added throughout. -- components: Library (Lib) messages: 243734 nosy: demian.brecht priority: normal severity: normal stage: needs patch status: open title: Replace debuglevel-related logic with logging type: enhancement versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24255 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data
Demian Brecht added the comment: Thanks for the report Rolf. I'll look into your suggestion for this patch. Antoine: Given beta is slated for the 24th and Martin's legitimate concerns, I think it might be a little hasty to get this in before feature freeze. Knocking it back to 3.6 (obviously feel free to change if you think it should remain for any reason). -- versions: +Python 3.6 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24255] Replace debuglevel-related logic with logging
Changes by Demian Brecht demianbre...@gmail.com: -- keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24255 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23377] HTTPResponse may drop buffer holding next response
Demian Brecht added the comment: Added comments to Rietveld. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23377 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data
Demian Brecht added the comment: BTW, thanks for the reviews Martin and the nudge Antoine! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data
Demian Brecht added the comment: Latest patch should address all outstanding comments. -- Added file: http://bugs.python.org/file39447/issue12319_6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data
Demian Brecht added the comment: What's the status on this one? It looks like some review comments need addressing. That's about it. Unfortunately I've been pretty tied up over the last month and a bit. I'll try to get to hopefully closing this out over the next few days. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23377] HTTPResponse may drop buffer holding next response
Demian Brecht added the comment: If nobody else gets to it first, I'll try to get to review this later today or tomorrow. Apologies for the delay on the review Martin, a new baby (coming next month), moving /and/ taking on a new job all at the same time seems to limit free time a little ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23377 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22931] cookies with square brackets in value
Demian Brecht added the comment: This needs a review from the people who created and applied the security patch. + Guido (committed https://hg.python.org/cpython/rev/9e765e65e5cb) -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24177] Add https?_proxy support to http.client
New submission from Demian Brecht: http_proxy and https_proxy are common environment variables used cross platform. Currently, urllib.request has support for it, but http.client does not. It probably should. If support is added to http.client, the handling of proxy environment variables in urllib.request should be factored out and made to be reliant on the changes in http.client (which shouldn't require any new code, only removal). Given the common usage of the environment variables (as observed by other utilities such as wget and curl), it seems odd to require a user to know about and use the higher level urllib.request API rather than have support for it baked into the lower level http.client API. -- components: Library (Lib) messages: 243101 nosy: demian.brecht, orsenthil, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Add https?_proxy support to http.client type: enhancement versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24177 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23888] Fixing fractional expiry time bug in cookiejar
Demian Brecht added the comment: LGTM, thanks for the patch! -- nosy: +r.david.murray stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23888 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23888] Fixing fractional expiry time bug in cookiejar
Demian Brecht added the comment: I left a small comment around indentation in Rietveld. Also, for the sake of completeness (and for others taking part in this review/commit), I dug through the relevant RFCs and none of them seem to define time as having sub-section resolution. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23888 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23888] Fixing fractional expiry time bug in cookiejar
Demian Brecht added the comment: Thanks for the follow up on that. In light of your findings, I agree with the path you've taken in your patch (and yeah, you'd have to deal with conversions in the output if you were to take my suggestion). I've left a couple minor comments in Reitveld. Other than those, the patch LGTM. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23888 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13567] HTTPError interface changes / breaks depending on what was passed to constructor
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13567 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24055] unittest package-level set up tear down module
New submission from Demian Brecht: There's a feature available via nose that might be nice to have in unittest: package-level setup and teardown functions. Using nose, I can define a setUpModule() method in a test package's __init__.py and it will execute it during the test run. This is helpful for test packages that test related features and may have expensive setup/teardown routines. By having the test runner pick up setup/teardown methods in __init__.py, I can now incur this expense once rather than once per module. I don't mind putting a patch together for this if others think this might be beneficial. -- components: Library (Lib) messages: 241981 nosy: demian.brecht, ezio.melotti, michael.foord, rbcollins priority: normal severity: normal stage: needs patch status: open title: unittest package-level set up tear down module type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24055 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23930] SimpleCookie doesn't parse comma-only separated cookies correctly
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23930 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23888] Fixing fractional expiry time bug in cookiejar
Demian Brecht added the comment: Although it's likely not going to be a high frequency issue (but would be painful to track down when it does become an issue), by doing an int(float(expires)), you're losing the sub-second portion of the expiry. Why not something like this: try: expires = int(expires) except ValueError: expires = int(float(expires) * 1e6) Looking at the values in the Chrome sqlite3 database, it seems like the above is what they're storing (INTEGER datatype). How are wget and curl treating the fractional part? I'd be really surprised if they were ignoring it as in the proposed patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23888 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23888] Fixing fractional expiry time bug in cookiejar
Demian Brecht added the comment: Changing to behavior type as crash is generally used to indicate an interpreter issue. -- nosy: +orsenthil stage: - patch review type: crash - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23888 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23377] HTTPResponse may drop buffer holding next response
Demian Brecht added the comment: I think it's ok to slightly break a non-public API since it's required to fix an obvious bug. To play devil's advocate here, /is/ this really non-public API? According to documented Python naming conventions, HTTPResponse is part of the public API. From code I've written myself, this would likely create a number of breakages. Granted, it would largely be in lower level testing code, but it would still create a headache. Is something that's lightly documented as being non-public take precedence over well known and used naming conventions? I'd argue no, it shouldn't. That said, I'm not overly enthused about the alternative Martin describes, so at first thought, I'm pretty much square on the fence about this. By the way, I guess we don't support HTTP pipelining, right? As Martin pointed out, sadly no. There's currently an internal state machine that seems to possibly be remnants of an initial implementation (just a guess, I haven't done any research into it to prove that though) that prevents pipelining. It's on my list of things to tackle as it seems to be a natural progression to HTTP/2.0 multiplexing, but unfortunately my time is a little shorter than usual at the moment (taking a new job has cut into my spare time a little). @Martin: I haven't had a chance to review the change in detail yet, but I think the idea's sound. I'll try to get some time over the next few days to dig into it further. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23377 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue23350 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23888] Fixing fractional expiry time bug in cookiejar
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23888 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23887] HTTPError doesn't have a good repr representation
Demian Brecht added the comment: A test really should be added for this. Otherwise, LGTM. -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23887 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23794] http package should support HTTP/2
Demian Brecht added the comment: @Cory: my own plan was to use your implementation as the baseline and add server support. If you take a crack at it that would be great! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23794 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23794] http package should support HTTP/2
Demian Brecht added the comment: +1 to the adding the support for HTTP/2. I would personally like to see a few things happen before that though (which I've been putting some effort into as i can) + refactor http.client to cleanly separate transport from application protocol level + figure out some kind of adapter interface in order to facilitate swapping between 1.1 and 2 (This can start with a clean HTTP/1.1 interface) + full HTTP/1.1 support. Given (as i understand it) HTTP/2 is largely an extension of HTTP/1.1 it doesn't make much sense to me to implement the latter before the former. -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23794 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22708] httplib/http.client in method _tunnel used HTTP/1.0 CONNECT method
Demian Brecht added the comment: Thanks for the report and follow up Vova. I've come across this line and it puzzled me as well as to why it's hardcoded. Rather than the hardcoded approach in your patch, I've attached a patch that uses _http_vsn_str which is consistent with other areas of the library. Additionally, I noticed that a failure will occur if the destination address contains characters outside of ASCII range, so I've added support for IDN. I assume that the patch should be committed to tip and maintenance branches as both issues are bugs (there is IDN support elsewhere in the library). -- nosy: +demian.brecht stage: resolved - patch review versions: -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file38808/issue22708.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22708 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8732] Should urrllib2.urlopen send an Accept-Encoding header?
Demian Brecht added the comment: This doesn't seem to be an issue in 3.4+, the following headers are injected in a call to urlopen(): GET / HTTP/1.1 Accept-Encoding: identity Host: example.com User-Agent: Python-urllib/3.4 Connection: close However, this is not the same behaviour in 2.7: GET / HTTP/1.0 Host: example.com User-Agent: Python-urllib/1.17 That said, I wouldn't see this as a bug but a feature request, so it should be invalid for 2.7. Setting this to pending to close unless anyone has any objections or further details. -- nosy: +demian.brecht status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8732 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.
Changes by Demian Brecht demianbre...@gmail.com: -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data
Changes by Demian Brecht demianbre...@gmail.com: Added file: http://bugs.python.org/file38797/issue12319_5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data
Demian Brecht added the comment: Agreed. However, I'm wondering if that should belong in a new issue geared towards further clarifying behaviour of request body types. The patch introduces the behaviour this specific issue was looking, with the largest change being that iterators may now result in chunked transfer encoding with the data currently handled by the library. I'd rather move forward with incremental improvements rather than keep building on each issue before the work's merged (there's still a /good/ amount of work to be done in this module). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23360] Content-Type when sending data with urlopen()
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23360 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data
Changes by Demian Brecht demianbre...@gmail.com: Added file: http://bugs.python.org/file38772/issue12319_4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23350 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue23350 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
Demian Brecht added the comment: Set as closed, assuming there's no reason to keep this issue open. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22931] cookies with square brackets in value
Changes by Demian Brecht demianbre...@gmail.com: -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22931] cookies with square brackets in value
Changes by Demian Brecht demianbre...@gmail.com: Added file: http://bugs.python.org/file38773/issue22931_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
Demian Brecht added the comment: Thanks for following up on this David. The changes you've made all look good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18828] urljoin behaves differently with custom and standard schemas
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 case.
I removed the gopher, wais, and imap schemes from the list
I'd be concerned about removing items as non_hierarchical /is/ public facing
and it's reasonable to assume that there are libraries out there that depend on
these. Additionally, at a glance through their respective RFCs, it seems that
these three protocols /do/ belong in the non_hierarchical list. While WAIS and
IMAP do use / as a delimiter, they're not hierarchical and therefore relative
joining doesn't make sense. For example, with the following definition in mind
(RFC4156):
wais://host:port/database/wtype/wpath
The following will result in an incorrect URL:
urljoin('wais://f...@bar.com/mydb/type/path', '/newpath')
However I am still not really convinced that my first urljoin-scheme.patch is
a bad idea. Do people actually use urljoin() with these schemes like mailto
in the first place?
I'd be inclined to agree that it's far from common practice. That said, I did
find one instance of a project that seems to depend on current behaviour
(although it's only in tests and I haven't looked any deeper):
https://github.com/chfoo/wpull/blob/32837d7c5614d7f90b8242e1fbb41f8da9bc7ce7/wpull/url_test.py#L637.
I imagine that the current behaviour may possibly be useful for utilities such
as web crawlers. In light of that and the fact that the urllib.parse docs
currently has a list of protocols that are intended to be supported across the
entire module's API, I think that it's important to not break backwards
compatibility in cases where the relative URL would have been returned. Your
second patch seems to have this behaviour which I think is preferable.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18828
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23778] Add a visual distinction to multiline versionchanged blocks
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 indentation (30px) to all but the first child. This change makes it much more obvious where the versionchanged block ends and the rest of the docs continue. -- assignee: docs@python components: Documentation files: versionchanged_indent.patch keywords: patch messages: 239261 nosy: demian.brecht, docs@python priority: normal severity: normal stage: patch review status: open title: Add a visual distinction to multiline versionchanged blocks type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38689/versionchanged_indent.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23778 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
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 rendered output. I've changed it as suggested as you're obviously more familiar with other instances of this, but I would still suggest reverting it to the three individual points if this isn't a docs best practice (or updating the versionchanged CSS class to have some visual distinction between it and the rest of the docs). -- Added file: http://bugs.python.org/file38688/http_cookies_morsel_deprecated_set_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
Demian Brecht added the comment: FWIW, I created #23778 to address the indentation issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23778] Add a visual distinction to multiline versionchanged blocks
Demian Brecht added the comment: Sounds good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23778 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23778] Add a visual distinction to multiline versionchanged blocks
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'm not sure that's something that's necessarily even wanted as such messages are intended to be terse. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23778 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
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.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
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/file38695/http_cookies_morsel_deprecated_set_3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22931] cookies with square brackets in value
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 here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data
Changes by Demian Brecht demianbre...@gmail.com: Added file: http://bugs.python.org/file38670/issue12319_3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data
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 existing HTTPConnection implementation. The original issue was that http.client doesn't support chunked encoding. With this patch, chunked encoding should more or less come for free with urlopen. There's absolutely no reason as to why HTTPConnection should not support transfer encoding out of the box given it's part of the HTTP1.1 spec. I do understand that there are some modifications needed in urllib.request in order to support the changes here, but I didn't include those in the patch as to not conflate the patch. I think that it's also reasonable to open a new issue to address the feature in urllib.request rather than piggy-backing on this one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23759] urllib.parse: make coap:// known
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 be to simply add documentation around manually adding schemes as required to uses_relative. -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23740] http.client request and send method have some datatype issues
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 the patch in #23350. @Martin text files could also be handled more consistently by checking the read() return type I wouldn't be opposed to this at all. In fact, I was going to initially make that change in #12319, but wanted to keep the change surface minimal and realistically, peeking at the data type rather than checking for 'b' in mode doesn't /really/ make that much of a difference. -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 header
for data types for which the size is known.
@Martin:
Technically I don’t think there is a bug.
The bug is that the Content-Length header is currently added for bodies that
are lists and tuples and the value is incorrect. For example:
con.request('POST', '/', ['aaa', 'bbb', 'ccc'])
results in
Host: example.com
Accept-Encoding: identity
Content-Length: 3
@David:
Since the latter cannot be done reliably unless we know the list or tuple is
all bytes, I propose that we don't do it at all (since I'd like to see
iterables of text strings supported).
The patch here adds support for iterables of text strings (as well as iterables
comprised of both bytes and strings). Content-Length can be computed reliably
as the size of a latin1-encoded string will be identical to the original string.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23350
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
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 sufficient heads up that their will be a breakage upcoming, however unlikely that the parameter is actually in use in practice. There's nothing lost by marking it deprecated and removing it for 3.6(+). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23662] Cookie.domain is undocumented
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23703] urljoin() with no directory segments duplicates filename
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 rep...@bugs.python.org http://bugs.python.org/issue23703 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23539] Content-length not set for HTTP methods expecting body when body is None
Demian Brecht added the comment: One super minor comment left in Rietveld (py3 patch). Otherwise LGTM. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23539 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
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, I'm not entirely sure what you're suggesting should be added (I'm also not overly familiar with what qualifies for what's new additions in the various categories without causing unnecessary noise). -- Added file: http://bugs.python.org/file38584/http_cookies_morsel_deprecate_set.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23703] urljoin() with no directory segments duplicates filename
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 tracker rep...@bugs.python.org http://bugs.python.org/issue23703 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18828] urljoin behaves differently with custom and standard schemas
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 rep...@bugs.python.org http://bugs.python.org/issue18828 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18828] urljoin behaves differently with custom and standard schemas
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 such as mailto? My initial reaction is no
and what should actually happen here is one of two things:
1. The result is a simple concatenation: mailto:f...@bar.com;.
2. An exception is raised indicating that urljoin cannot determine how to
handle merging base and url.
The above could happen in cases where either scheme is None for both base and
url or the scheme to be used is any of urllib.parse.non_hierarchical.
A more awkward question is if this behaviour of my patch is reasonable:
urljoin('mailto:person-foo/b...@example.net', 'bar.com')
'mailto:person-foo/bar.com'
A couple thoughts on this: If urllib.parse.non_hierarchical is used to
determine merge vs. simple concat (or exception), this specific case won't be
an issue. Also, according to 6068, mailto:person-foo/b...@example.net' is
invalid (the / should be percent-encoded), but I don't think it should be the
job of urljoin to understand the URI structures of each protocol, outside of
logically join base and url.
Yet another option, similar to my “any_scheme=True” flag, might be to change
from the “uses_relative” white-list to a “not_relative” black-list of URL
schemes, so that urljoin() works for arbitrary schemes except for ones like
“mailto:” that are in the hard-coded list.
This list may already be present in urllib.parse.non_hierarchical. I also think
it's worthwhile to do some further research against
http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml to ensure the
list is up to date.
If this path is chosen, I would suggest getting sign off from a couple core
devs prior to investing time in this as all changes discussed so far are
backwards incompatible.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18828
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
Demian Brecht added the comment: Thanks for the follow up Serhiy, LGTM. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22852] urllib.parse wrongly strips empty #fragment
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). At first read of #23505, I think I agree with the changes you've made to allow for successful round-tripping, but I'd think it'll have to be vetted by at least more than one core dev. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22852 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
Demian Brecht added the comment: Thanks for the updates Serhiy. All look good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
Changes by Demian Brecht demianbre...@gmail.com: -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18828] urljoin behaves differently with custom and standard schemas
Changes by Demian Brecht demianbre...@gmail.com: -- stage: - patch review versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18828 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18828] urljoin behaves differently with custom and standard schemas
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@', 'bar.com')
'mailto:bar.com/bar.com'
I'm taking an educated guess here based on a marginal amount of research (there
are just a few registered schemes at
http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml that should be
understood), but it /seems/ like perhaps the current behaviour is intended to
safeguard against joining non-hierarchical schemes in which case you'd get
nonsensical values. It does seem a little odd to me, but I definitely prefer
the former behaviour to the latter.
I think that short term, Madison's suggestion about documenting uses_relative
would be an easy win and can be applied to all branches. Long term though, I
think it would be nice to have a generalized urljoin() method that accounts for
most (if not all) classifications of url schemes.
Thoughts?
--
nosy: +demian.brecht
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18828
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22931] cookies with square brackets in value
Changes by Demian Brecht demianbre...@gmail.com: Removed file: http://bugs.python.org/file38522/issue22931_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23684] urlparse() documentation does not account for default scheme
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 rep...@bugs.python.org http://bugs.python.org/issue23684 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22931] cookies with square brackets in value
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 issue, but the change was made for good reason. -- Added file: http://bugs.python.org/file38522/issue22931_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22931] cookies with square brackets in value
Changes by Demian Brecht demianbre...@gmail.com: Added file: http://bugs.python.org/file38525/issue22931_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data
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 bug where chunk size was being sent as decimal instead of hex -- Added file: http://bugs.python.org/file38528/issue12319_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22852] urllib.parse wrongly strips empty #fragment
Demian Brecht added the comment:
urlsplit(evil.com).netloc
''
urlsplit(evil.com).has_netloc
True
urlunsplit(urlsplit(evil.com)) # Adds “//” back
'evil.com'
RFC 3986, section 3.3:
If a URI contains an authority component, then the path component
must either be empty or begin with a slash (/) character. If a URI
does not contain an authority component, then the path cannot begin
with two slash characters (//).
Because this is a backwards incompatible behavioural change and is just as
invalid as far as the RFC goes, I think that the current behaviour should be
preserved. Even though it's still incorrect, it won't break existing code if
left unchanged.
## _NetlocResultMixinBase abuse ##
The _NetlocResultMixinBase class is a common class used by the four result
classes I’m interested in. I probably should rename it to something like
_SplitParseMixinBase, since it is the common base to both urlsplit() and
urlparse() results.
I think I'm coming around to this and realizing that it's actually quite close
to my proposal, the major difference being the additional level of hierarchy in
mine. My issue was mostly due to the addition of the variadic signature in the
docs (i.e. line 407 here:
http://bugs.python.org/review/22852/diff/14176/Doc/library/urllib.parse.rst)
which led me to believe a nonsensical signature would be valid. After looking
at it again, __new__ is still bound to the tuple's signature, so you still get
the following:
SplitResult('scheme','authority','path','query','fragment','foo','bar','baz')
Traceback (most recent call last):
File stdin, line 1, in module
File /Volumes/src/p/cpython/Lib/urllib/parse.py, line 137, in __new__
self = super().__new__(type, *pos, **kw)
TypeError: __new__() takes 6 positional arguments but 9 were given
So I'm less opposed to this as-is. I would like to see the * removed from the
docs though as it's misleading in the context of each of (Split|Parse)Result. I
do agree that renaming _NetlocResultMixinBase would be helpful, but it might
also be nice (from a pedant's point of view) to remove mixin altogether if
the __new__ implementation stays as-is.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22852
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2211] Cookie.Morsel interface needs update
Changes by Demian Brecht demianbre...@gmail.com: Added file: http://bugs.python.org/file38509/issue2211_5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22852] urllib.parse wrongly strips empty #fragment
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 there a reason to add them to
the __init__ methods?
I'd also like to see this logic moved out of _NetlocResultMixinBase. I'm
assuming it was put there for backwards compatibility which is understandable,
but I don't think it makes sense to add such logic to a mixin who's purpose is
additional functionality around the netloc attribute. This one's a little more
subjective though, but here's a rough idea of what I'm thinking:
SplitResult = namedtuple('SplitResult', 'scheme netloc path query fragment')
class _SplitResultBase(SplitResult):
def __new__(cls, scheme, netloc, path, query, fragment):
inst = super().__new__(cls, scheme, netloc, path, query, fragment)
inst.has_netloc = bool(netloc)
return inst
s = urlsplit('http://example.com/foo/bar/')
s.has_netloc
True
This keeps backwards compatibility, but also adds the additional logic to the
bases rather than in the mixins. I might also split out the logic into helper
functions in order to avoid duplication between _SplitResultBase and
_ParseResultBase.
This method also avoids the dependency on ordering of base classes as well as
the addition of a variadic signature to (Split|Parse)Result.__init__.
Thoughts?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22852
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22852] urllib.parse wrongly strips empty #fragment
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 rep...@bugs.python.org http://bugs.python.org/issue22852 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
