[issue2193] Cookie Colon Name Bug

[John J Lee]

John J Lee  added the comment:

I agree with And Clover that Carsten Klein's comments in #msg127366 are not 
correct, for the reason that And stated.

Also, Carsten repeats again the idea that the trac issue is about the trac 
server failing to generate appropriate cookies -- but that issue was in fact 
about trac's processing of cookies generated by servers other than trac.  In 
that particular case, the other server was probably under the control of the 
same group of people, but that isn't true in general.  Please read all the 
comments before adding more comments.

Re #msg127368: I don't think the patch applied to trac is relevant here.  
"Somebody" should write a patch for module Cookie, and then it can be reviewed.

--

___
Python tracker 
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

[John J Lee]

John J Lee  added the comment:

Yes, interoperability is good.  Do you have a specific concern about the change 
that I proposed?

If not, and you're instead just trying to ensure conformance, by all means read 
the draft specification that you pointed out and look for reasons why my 
suggested change would be the wrong thing to do -- that would certainly be 
useful.  Otherwise, it's hard to respond to non-specific "are you doing the 
right thing" questions with anything other than "yes" ;-)

--

___
Python tracker 
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

[John J Lee]

John J Lee  added the comment:

Yes, interoperability is good.  Do you have a specific concern about the change 
that I proposed?

If not, and you're instead just trying to ensure conformance, by all means read 
the draft specification that you pointed out and look for reasons why my 
suggested change would be the wrong thing to do -- that would certainly be 
useful.  Otherwise, it's hard to respond to non-specific "are you doing the 
right thing" questions with anything other than "yes" ;-)

--

___
Python tracker 
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

[John J Lee]

John J Lee  added the comment:

Again, I don't think this is relevant, because the bug is about servers parsing 
Cookie: headers.  Note that that string (the value of the Cookie: header) may 
be generated by a different server than the server that parses it (see the trac 
example mentioned in the bug comments).

--

___
Python tracker 
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

[John J Lee]

John J Lee  added the comment:

karl: I'm not clear precisely what it is that you want to draw our attention 
to.  Note this bug is about parsing of Cookie headers by servers, not 
production of Set-Cookie headers by servers.

--

___
Python tracker 
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1520831] urrlib2 max_redirections=0 disables redirects

[John J Lee]

John J Lee  added the comment:

Oops, I hadn't noticed that max_redirections isn't part of the API.  In that 
case, I agree that it's not strictly a bug.  I'd also agree it's not very 
important.

FWIW: "want[ing] to see all redirects" is not the same thing as printing URLs 
-- I assume he simply meant that he wanted .open to return the original 
response, and not a redirected response.  I don't think he meant that he wanted 
urllib2 itself to allow him to literally see the URLs on his screen, by 
printing them to stdout (!).

--

___
Python tracker 
<http://bugs.python.org/issue1520831>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1520831] urrlib2 max_redirections=0 disables redirects

[John J Lee]

John J Lee  added the comment:

That's silly.  A justification of the need for a new feature isn't needed, 
because this is already-implemented feature that simply does the wrong thing at 
the edge case.

It's not high priority, but it is a bug.

--

___
Python tracker 
<http://bugs.python.org/issue1520831>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1520831] urrlib2 max_redirections=0 disables redirects

[John J Lee]

John J Lee  added the comment:

Why not?

--

___
Python tracker 
<http://bugs.python.org/issue1520831>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

[John J Lee]

John J Lee  added the comment:

dstanek> Would it be better to file bugs against buggy implementations instead 
of changing Python's implementation to be more lenient?

No.  Another app running on the same domain that knows nothing about RFC 2109 
(and why should it?) shouldn't break your Cookie.py-using app -- did you look 
at the trac bug?

--

___
Python tracker 
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2193] Cookie Colon Name Bug

[John J Lee]

John J Lee  added the comment:

Looks like a bug.  Here's the trac bug that this caused -- trac fixed their bug 
by working around this bug in a really ugly way:

http://trac.edgewall.org/ticket/2256

It would be nice to notify the trac developers if/when this is fixed.

This bug is probably not specific to colons (e.g. commas used to be valid in 
HTTP cookie strings, and still are as far as I know -- somebody should test 
what current browsers do to make sure).  The set of characters regarded as 
legal is less important than the fact that parsing a Cookie header should 
*never* raise CookieError -- it should just ignore any invalid cookies.  Still, 
IIRC there isn't any need to treat any of them as invalid, since more or less 
anything is a valid cookie (or was in the past -- as I say, maybe browsers have 
cleaned up since then, but I'd be surprised).

--

___
Python tracker 
<http://bugs.python.org/issue2193>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1660009] continuing problem with httplib multiple set-cookie headers

[John J Lee]

John J Lee  added the comment:

What I said in 2007 re commas could be well out of date (might well have been 
so even then, in fact).  Somebody should check what browsers do now...

--

___
Python tracker 
<http://bugs.python.org/issue1660009>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3704] cookielib doesn't handle URLs with / in parameters

[John J Lee]

John J Lee  added the comment:

Hmm, I never tested with Python 3, though I assume the forward-port was 
straightforward.  The patch was created against (2.x) trunk, so indeed it 
should be committed there also.

Deselecting 2.6 since I assume no more maintenance backports will be made to 
2.6 aside from security fixes -- right?

--
versions:  -Python 2.6

___
Python tracker 
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3704] cookielib doesn't handle URLs with / in parameters

[John J Lee]

John J Lee  added the comment:

My patch should be applied.

--

___
Python tracker 
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2190] MozillaCookieJar ignore HttpOnly cookies

[John J Lee]

John J Lee  added the comment:

Is deprecation really necessary?  lynx still uses that format.  lynx doesn't 
write the header that MozillaCookieJar insists on being present, but a trivial 
subclass can read cookies files written by lynx.

--

___
Python tracker 
<http://bugs.python.org/issue2190>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2277] MozillaCookieJar does not support Firefox3 cookie files

[John J Lee]

John J Lee  added the comment:

There is code in PyPI project mechanize that implements this feature.  That 
code is marked experimental though, due to lack of testing.

--
nosy: +jjlee

___
Python tracker 
<http://bugs.python.org/issue2277>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8975] Bug in cookiejar

[John J Lee]

John J Lee  added the comment:

This is a duplicate of issue3924

--
nosy: +jjlee

___
Python tracker 
<http://bugs.python.org/issue8975>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2007] cookielib lacks FileCookieJar class for Internet Explorer

[John J Lee]

John J Lee  added the comment:

Suggest removing the comment that Terry refers to.  That referenced MSIE code 
doesn't have an automated test, I've no idea whether it still works on modern 
Windows OSes, mechanize no longer supports use with urllib2, and I don't think 
that link is really appropriate in the docs anyway -- Google will likely give 
people more accurate information.

--

___
Python tracker 
<http://bugs.python.org/issue2007>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3704] cookielib doesn't handle URLs with / in parameters

[John J Lee]

John J Lee  added the comment:

What specific breakage do you expect resulting from my patch being backported?

There is no behaviour change here, except to the minimal extent that all bug 
fixes involve behaviour change.  This seems a clear-cut backport candidate.

It's not a surprise to me that changing module urlparse to be compliant with 
RFC 3986 breaks code -- I suggested adding a new module instead for that reason.

--

___
Python tracker 
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3704] cookielib doesn't handle URLs with / in parameters

[John J Lee]

John J Lee  added the comment:

FWIW, the "certain semantics" that request_path "promises" are 1. that it 
returns the RFC 2965 request-URI (which has never been true -- it returns the 
path component of the request-URI instead) and 2. that that request-URI is as 
defined in RFC 2965, and this bug is about fixing the function so that that's 
true for the case where the URI has a query component.  So there's absolutely 
no reason for not changing the function.

--

___
Python tracker 
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3704] cookielib doesn't handle URLs with / in parameters

[John J Lee]

John J Lee  added the comment:

Didn't bother changing docstring to comment, since that would be inconsistent 
with rest of module.

--

___
Python tracker 
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3704] cookielib doesn't handle URLs with / in parameters

[John J Lee]

Changes by John J Lee :


Added file: http://bugs.python.org/file17285/issue3704.patch

___
Python tracker 
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3704] cookielib doesn't handle URLs with / in parameters

[John J Lee]

John J Lee  added the comment:

Just re-read your comment, Tres.  Since when do docstrings determine whether a 
stdlib function is public?  If it's documented in the docs, it's public.  If 
not, it's not.  This function isn't, so it's not public.  It's also not in 
__all__, FWLTW.

--

___
Python tracker 
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3704] cookielib doesn't handle URLs with / in parameters

[John J Lee]

John J Lee  added the comment:

I'll upload a patch when I'm back home (bugs.python.org went down yesterday).

Will turn docstring into comment.

--

___
Python tracker 
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5537] LWPCookieJar cannot handle cookies with expirations of 2038 or greater on 32-bit platforms

[John J Lee]

John J Lee  added the comment:

Shouldn't module time be changed to use a cross-platform implementation that 
uses a 64 bit time_t-like type?  Apparently Perl 6 has made the equivalent 
change.

Admittedly there seems to be no sign of that actually happening.

--
nosy: +jjlee

___
Python tracker 
<http://bugs.python.org/issue5537>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6588] insert cookies into cookie jar - cookielib.py

[John J Lee]

John J Lee  added the comment:

Jon,

If you want to get these changes applied you need to:

 1. Split up these three separate issues
 2. Most important: explain in full detail exactly how you used cookielib, what 
you expected it to do, and what it actually did, and then justify why your 
expectation is correct.
 3. Ensure that automated tests cover each change
 4. Respond to the review comments that are likely to follow

--
nosy: +jjlee

___
Python tracker 
<http://bugs.python.org/issue6588>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3704] cookielib doesn't handle URLs with / in parameters

[John J Lee]

John J Lee  added the comment:

It looks to me that it's just request_path that's wrong, so no need to add 
extra arguments to that function.  It should discard the query and fragment 
(still keeping the "parameters" -- using urlparse.urlsplit instead of 
urlparse.urlparse would make that simpler).

request_path is only called in three places:

 * We're agreed that the default cookie path should omit the query (and 
fragment)
 * Netscape cookies aren't checked for path on setting cookies 
(.set_ok_path()), so the value of request_path isn't checked in that case
 * Netscape cookies are checked for path on returning cookies, but including 
the query & fragment will never make a difference to the .startswith check in 
.path_return_ok()

Finally, even RFC 2965, which nobody cares about, and which does include the 
path check on setting the cookie, refers to RFC 2396 for the definition of 
request-URI, and both RFC 2396 and RFC 3986, which obsoletes it, agree that the 
path doesn't include the query (nor the fragment).

Incidentally: the request_path function docstring claims to return the 
request-URI, but obviously the docstring should say it returns the path 
component of the request-URI.

--

___
Python tracker 
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir

[John J Lee]

John J Lee  added the comment:

> Yes,it currently does not handle chained redirects via cache. I dont know 
> RFC's stance on it. RFC does not say anything about 301 chained redirects

I don't see anything in the RFC that prevents us caching chained 301 
redirections.  Caching the chained redirections is better, because it reduces 
the number of requests, which is the purpose of the cache.

> there are tricker issues of caching anything other than 301.

Antoine wasn't suggesting caching URLs from non-301 responses, just that you 
don't need to add a new method named "http_redirect_301".  Just delete it and 
test "if code == 301" in http_error_302.

> Basically, 302 and other require the client to check and comply with the 
> Cache-Control and Expires header.

I don't think references to caching in the descriptions of the 30* response 
codes are relevant, because urllib2 doesn't implement response caching.  I 
think the part that's relevant is this: "The requested resource has been 
assigned a new permanent URI and any future references to this resource SHOULD 
use one of the returned URIs."

> The global opener seems to be a straight forward way to for this activity and 
> not a harmful too.  I can't think of request-specific object for this one.

No.  The global OpenerDirector instance is a convenience to allow having a 
global urlopen() function.  Having a handler pick a random opener object (the 
global one) would be insane.

--

___
Python tracker 
<http://bugs.python.org/issue1755841>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir

[John J Lee]

John J Lee  added the comment:

To make sure I understood something Antoine said:  By "per-request", I assume 
you mean the same kind of thing as the current use of .redirect_dict -- the 
multiple urllib2.Request instances that may result from a single request passed 
by the user to .open()/urlopen all sharing the same cache state.

In addition to what Antoine said:

 0. patch reports that your latest patch is malformed (see below).
 1. I'm afraid I think any 301 caching that's not per-request should be off by 
default.  Defaulting to on would be a significant change in behaviour, because 
urllib2.urlopen (and OpenerDirector.open) currently retains no state between 
calls (unless you add a handler that keeps state, such as HTTPCookieProcessor, 
but no such handlers are added by default).
 2. I imagine the code changes should be entirely (or almost entirely) confined 
to RedirectHandler and/or AbstractHTTPHandler.  Is there any justification for 
changing OpenerDirector?  Certainly no need to add any globals!
 3. http_error_30x is a documented interface, but it's not frequently used.  
The argument(s) used to control caching should be somewhere else (see questions 
below).
 4. Please do post the doc changes for review once the implementation is 
decided on.


Some questions to consider:

 a. How should POST requests be handled when there is a cached permanent 
redirect URI?
 b. How useful is per-request caching, in the sense defined above (as opposed 
to per-user agent caching -- i.e. per-handler in our case)?  Best answered with 
data from the web.
 c. Should URIs be normalised before being used as a cache key?
 d. Might the cache get big?

For all #a, #b, #c, #d: What do existing implementations (e.g. Firefox) do?


$ patch -p0 < urllib2-301-redirection-proper.diff
patching file Lib/urllib2.py
Hunk #3 succeeded at 549 with fuzz 2 (offset 18 lines).
Hunk #4 succeeded at 562 (offset 18 lines).
patch:  malformed patch at line 55: @@ -604,8 +618,12 @@

$ patch --version
patch 2.5.9
Copyright (C) 1988 Larry Wall
Copyright (C) 2003 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall and Paul Eggert

--

___
Python tracker 
<http://bugs.python.org/issue1755841>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1424148] urllib.FancyURLopener.redirect_internal looses data on POST!

[John J Lee]

John J Lee  added the comment:

If you have a feature request, please open a separate ticket.  This one 
is about an alleged bug.

--

___
Python tracker 
<http://bugs.python.org/issue1424148>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1424148] urllib.FancyURLopener.redirect_internal looses data on POST!

[John J Lee]

John J Lee  added the comment:

This issue is not a bug, and should be closed.  It was discussed at 
length many years ago (different bug tracker ticket), and resolved.  
Since then the same issue seems to come up every year or so, 
apparently raised by people who haven't checked the issue tracker for 
previous discussion.  Please, somebody close this issue!


> It seems to be an old one.
> urllib2 still claim (as of python 2.6) the following;
> 
> # Strictly (according to RFC 2616), 301 or 302 in response
> # to a POST MUST NOT cause a redirection without confirmation
> # from the user (of urllib2, in this case).  In practice,
> # essentially all clients do redirect in this case, so we
> # do the same.

Note that this is NOT a statement about whether the request sent as a 
result of the redirect response contains the original POST data.


> This is just not true, we don't do the same at all. redirect_request
> does not pass data along and it even changes the headers to reflect
> content-size, thus behaving perfectly in accordance with RFC.

This appears to be a statement about (amongst other things) whether 
the request sent as a result of the redirect response contains the 
original POST data.

So where's the connection between the comment you quote and your 
response to it, Giorgio?  Actually, I hope you don't mind if I ask you 
not to answer that question, but instead to go and read, very 
carefully, the tracker discussion for the original fix that introduced 
the comment you posted (you should be able to find it by svn 
annotating the source, finding the appropriate commit, then looking 
for a reference in the commit message to a bug tracker issue ID).  
Once you've done that, please stop posting on this issue <0.2 wink>

Sorry, I'm not normally this grumpy, but this issue just seems to keep 
coming back forever, because people haven't spent the time to test 
browser behaviour, carefully read the RFC, tracker discussion, commit 
messages, etc.  If you have done all that and thought carefully and 
still think there's a bug, by all means come back, but please make 
sure you're extremely clear about *exactly* what you think is wrong, 
and why.  Write a test case, and cite specific RFC wording.  If what 
you think is wrong is not the same as the original issue described in 
the opening comment of this bug tracker ticket, please raise a new 
ticket rather than commenting on this one.


> For those who stumbled upon this page looking for a workaround, this 
is
> how to do: create a new class inheriting from HTTPRedirectHandler 
and
> use this one instead:

I don't know what this is a workaround *for*.

--

___
Python tracker 
<http://bugs.python.org/issue1424148>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue991266] Cookie.py does not correctly quote Morsels

[John J Lee]

Changes by John J Lee :


--
nosy:  -jjlee

___
Python tracker 
<http://bugs.python.org/issue991266>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1172011] BaseCookie does not call value_decode

[John J Lee]

Changes by John J Lee :


--
nosy:  -jjlee

___
Python tracker 
<http://bugs.python.org/issue1172011>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1372650] Cookie and multiple names

[John J Lee]

John J Lee  added the comment:

A patch for this bug is attached to issue1375011.

___
Python tracker 
<http://bugs.python.org/issue1372650>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue918368] urllib doesn't correct server returned urls

[John J Lee]

John J Lee  added the comment:

Uh, that should have beeen something like
.open("spam://example.com/%2E/") of course.

___
Python tracker 
<http://bugs.python.org/issue918368>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue918368] urllib doesn't correct server returned urls

[John J Lee]

John J Lee  added the comment:

A suitable test would be to derive a urllib.URLOpener subclass that has
an open_spam(url) method which records the URL.  Then call
.open("spam://") in the test and verify that the URL has been quoted.

___
Python tracker 
<http://bugs.python.org/issue918368>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue918368] urllib doesn't correct server returned urls

[John J Lee]

John J Lee  added the comment:

Mike's list is missing one more character, "%" itself.  So, the
replacement should be:

quote(newurl, safe="%/:=&?~#+!$,;'@()*[]")

The replacement should be done in the .open() method, not in the code
that handles redirects.

___
Python tracker 
<http://bugs.python.org/issue918368>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1153027] http_error_302() crashes with 'HTTP/1.1 400 Bad Request

[John J Lee]

John J Lee  added the comment:

This bug refers to urllib2.  Issue 918368 refers to urllib.  It's the
same problem in each case, though.

___
Python tracker 
<http://bugs.python.org/issue1153027>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue918368] urllib doesn't correct server returned urls

[John J Lee]

John J Lee  added the comment:

This bug refers to urllib.  Issue 1153027 refers to urllib2.  It's the
same problem in each case, though.

--
nosy: +jjlee

___
Python tracker 
<http://bugs.python.org/issue918368>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1660009] continuing problem with httplib multiple set-cookie headers

[John J Lee]

John J Lee  added the comment:

Why?

___
Python tracker 
<http://bugs.python.org/issue1660009>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1401] urllib2 302 POST

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

I think this was actually not a bug, and the fix should not have been
applied.  I guess this comment is just "for the record", as the fix is
probably cruft that can't be removed now, since people will have started
relying on it.

The only way that the Content-Length header could be in req.headers in
the first place is if the user had explicitly requested that it be added
(urllib2 adds that header to .unredirected_hdrs, but not to .headers). 
The user can no doubt provoke all kinds of other errors by adding random
HTTP headers -- what makes this particular one special?  .add_header()
has always been a "you need to know what you're doing, or you'll break
stuff" interface, and it's not really possible to "fix" that (at least
not without changing the meaning of .add_header()).

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1401>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4496] misleading comment in urllib2

[John J Lee]

Changes by John J Lee <[EMAIL PROTECTED]>:


--
components: +Library (Lib)
nosy: +facundobatista
versions: +Python 2.7, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4496>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4496] misleading comment in urllib2

[John J Lee]

New submission from John J Lee <[EMAIL PROTECTED]>:

r54137 replaced a comment in urllib2.py with a misleading comment.  The
comment now implies the .insort() in question achieves the goal
specified in the new comment.  That's not true, which was the reason the
original comment was there in the first place.

At least replace the comment with the original comment.  Alternatively,
(correctly) resolve the question in the original comment somehow (for
example by removing the .handlers attribute -- but since .handlers is
misnamed in not having an initial underscore, it may have tempted people
to use it, even though it's undocumented, hence private).

--
messages: 76783
nosy: jjlee
severity: normal
status: open
title: misleading comment in urllib2

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4496>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2464] urllib2 can't handle http://www.wikispaces.com

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

I've raised #4493 about the issue I raised in my previous comment.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2464>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4493] urllib2 doesn't always supply / where URI path component is empty

[John J Lee]

New submission from John J Lee <[EMAIL PROTECTED]>:

As required by RFC 2616 section 3.2.2, for all HTTP requests sent by
urllib2, the path component of the URI should be normalized to "/"
before the Request-URI derived from it gets passed to httplib (or
something functionally equivalent to that).  This was fixed in one case
in #2464, but the fix is in the wrong place, since it's a general
problem not specific to redirects.  See the longer discussion here:

http://bugs.python.org/msg76736

(hmm, let's see if I can just say msg76736 and get a hyperlink)

Example:

import urllib2
urllib2.urlopen("http://python.org?spam";)

Expect: sends "/?spam" in request line.

Got: sends "?spam" in request line.

Probably should be fixed by making Request.get_selector() return the
normalized URI reference (with the slash always present).  When fixing,
remember that the Request-URI of RFC 2616 (returned by .get_selector())
is sometimes a relative reference, and sometimes a URI (in RFC 3986's
terminology).

--
messages: 76777
nosy: jjlee
severity: normal
status: open
title: urllib2 doesn't always supply / where URI path component is empty

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4493>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4079] new urllib2.Request 'timeout' attribute needs to have a default

[John J Lee]

Changes by John J Lee <[EMAIL PROTECTED]>:


--
nosy: +facundobatista

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4079>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4079] new urllib2.Request 'timeout' attribute needs to have a default

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

This bug was known before the release -- unfortunately the original
author of the patch didn't fix them in time.  This and some other
unresolved issues listed are listed on #2451.  "Somebody" should raise
bugs about the rest of them too, and fix them.

(Senthil, is that the bug you meant to refer to?  You pasted this bug's
own URL here, presumably you meant to paste the URL for a different bug?)

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4079>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1772481] urllib2 hangs with some documents.

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Please close: this is already fixed on trunk and release25-maint
(r60747, issue #1966) (and on release26-maint, which was branched after
the fix).

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1772481>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1411097] httplib patch to make _read_chunked() more robust

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

For the record, I think my worry in msg49366 was a non-issue: the only
time .readline() will return "" is when the connection has closed (so I
think the fix that eventually applied is correct).

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1411097>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue900744] catch invalid chunk length in httplib read routine

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

The fix for this doesn't actually close the connection as the comment in
the fix claims -- I've raised #4492 to track that.

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue900744>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4492] httplib code thinks it closes connection, but does not

[John J Lee]

New submission from John J Lee <[EMAIL PROTECTED]>:

The fix for #900744 tried to close the connection when a bad chunk
length was received.  The comment inserted with that fix "close the
connection as protocol synchronisation is probably lost" is incorrect:
self.close() in _read_chunked does not close the connection.  You have
to call HTTPConnection.close() to close the connection.

So:

 * The comment is incorrect, and should be removed or fixed.  I guess
the self.close() should stay.

 * It's probably a bug that it doesn't result in the connection being
closed.  I guess a fix for that would be for the HTTPResponse to set
some state on itself that HTTPConnection can query so that
HTTPConnection can close itself the next time somebody tries to do
something with the connection.

--
components: Library (Lib)
messages: 76764
nosy: jjlee
severity: normal
status: open
title: httplib code thinks it closes connection, but does not
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4492>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1123695] attempting to use urllib2 on some URLs fails starting on 2.4

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Can somebody close this?  It's fixed on trunk in #900744 .

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1123695>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1537445] urllib2 httplib _read_chunked timeout

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

urlopen() raises URLError, .read() may raise other errors.  I don't
think that's a bug in itself, though no doubt:

 1. The documentation of exceptions raised could and should be improved
 2. The exceptions that can be raised are likely still inconsistent
(though this has improved in Python 2.6, I think)

Recommend closing this bug.

Please open other bugs about the issues above if you have patches.

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1537445>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1205] urllib fail to read URL contents, urllib2 crash Python

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

This is fixed in trunk r61034 by issue #900744 .  Please use that issue
for any discussion re whether this should be fixed in 2.5.

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1205>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3819] urllib2 sends Basic auth across redirects

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

I agree this is a bug.

Senthil -- re "1)", the paragraph you refer to (quoted by the OP) is
relevant.  The fact that it doesn't specifically mention redirection is
not relevant.

Re "2)": I don't know how digest auth works, but the paragraph you quote
from appears to be there for explanation rather than for prescribing how
digest auth or HTTP work (i.e. it appears to be "non-normative").  This
bug doesn't say that redirected requests shouldn't contain the
Authorization header.  It says that the Authorization header for an old
request shouldn't be sent with a new request (though it may turn out the
new one is equal to the old one in some cases).

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3819>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2464] urllib2 can't handle http://www.wikispaces.com

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

This fix was applied in the wrong place.

URI path components, and HTTP URI path components in particular, *can*
be empty.  See RFC 3986.  So the comment in the code that was inserted
with the fix for this bug that says "possibly malformed" is incorrect,
and should instead just refer to section 3.2.2 of RFC 2616.  Also,
because 3.2.2 says "If the abs_path is not present in the URL, it MUST
be given as "/" when used as a Request-URI for a resource (section
5.1.2)", it seems clear that this transformation (add the slash if
there's no path component) should always happen when retrieving URIs,
regardless of where the URI came from -- not only for redirects.

Note that RFC 2616 incorrectly claims to refer to the definition of
abs_path from RFC 2396.  The fact that it's incorrect is made clear in
2616 itself, in section 3.2.3, when it says that abs_path can be empty.
 In any case, RFC 2396 is obsoleted by RFC 3986, which is clear on this
issue, and reflects actual usage of URIs.  URIs like http://python.org
and http://python.org?spam=eggs have been in widespread use for a long
time, and typing the latter URL into firefox (3.0.2) confirms that
what's actually sent is "/?spam", whereas urllib2 still sends "?spam".

No test was added with this fix, which makes it unnecessarily hard to
work out what exactly the fix was supposed to fix.  For the record, this
is the sequence of redirections before the fix was applied (showing base
URI + redirect URI reference --> redirect URI):

'http://www.wikispaces.com' +
'https://session.wikispaces.com/session/auth?authToken=token' -->
'https://session.wikispaces.com/session/auth?authToken=token'
'https://session.wikispaces.com/session/auth?authToken=token' +
'http://www.wikispaces.com?responseToken=token' -->
'http://www.wikispaces.com?responseToken=token'

and after the fix was applied:

'http://www.wikispaces.com' +
'https://session.wikispaces.com/session/auth?authToken=token' -->
'https://session.wikispaces.com/session/auth?authToken=token'
'https://session.wikispaces.com/session/auth?authToken=token' +
'http://www.wikispaces.com/?responseToken=token' -->
'http://www.wikispaces.com/?responseToken=token'
'http://www.wikispaces.com/?responseToken=token' +
'http://www.wikispaces.com/' --> 'http://www.wikispaces.com/'

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2464>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3924] cookielib chokes on non-integer cookie version, should ignore it instead

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

The bug is present on trunk and on the py3k branch, so I've selected
versions "Python 2.7" and "Python 3.0"

This is a straightforward bug, so I selected 2.5.3 and 2.6 also, to
indicate this is a candidate for backport.

--
components: +Library (Lib) -None
type: crash -> behavior
versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3924>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3924] cookielib chokes on non-integer cookie version, should ignore it instead

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Patch with tests attached.  The patch is slightly different to my first
suggestion: in the patch, invalid version values cause the cookie to be
ignored (but double quotes around valid versions are fine).

--
keywords: +patch
Added file: http://bugs.python.org/file11888/issue3924.patch

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3924>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2756] urllib2 add_header fails with existing unredirected_header

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

I agree there is a bug here: clearly the methods on the Request class
are inconsistent with AbstractHTTPHandler.do_open() .  I think Facundo's
patch is good, though it needs a test.

The general principle when fixing earlier bugs has been that the
.add_*header() methods override default headers, though there are some
reasonable violations this where the implementation relies on specific
headers being sent -- e.g. "Connection: close".

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2756>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

Changes by John J Lee <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file11887/issue2775-problems.patch

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

I have attached a patch that just:

 * Improves doctests a bit
 * Changes .get_headers() and .has_header() to be case-insensitive
 * Documents .get_header() and .header_items(), fixes some
incorrectly-documented argument names, and notes the case-sensitivity change
 * Note that the headers passed to httplib (the original issue for which
this bug was raised) were already correctly Title-Cased, and that is
unchanged by this patch

Options:

 * Apply my patch.  I'd be happy with this.
 * Apply my patch and begin the process of deprecating public interfaces
.unredirected_hdrs and .headers.  Perhaps provide another interface to
tell whether a header will be redirected (only if there's a use case for
that).  I'd be happy with this too.
 * Bring back Senthil's case-normalized .headers and .unredirected_hdrs
and document those interfaces.  This a bad idea, because this would
result in a very confusing set of interfaces for dealing with headers
(see my previous comments on this -- Date: 2008-07-11 19:44).

(For what it's worth, I have also attached a doctest to show some
examples of the broken invariants issue with Senthil's patch.  The
doctest also comments on the fact that making .headers case-insensitive
in this way is quite confusing in the case where multiple items of
different case are present, but __getitem__ returns only a single item
-- this is a relatively minor issue, but still worth avoiding.  The
variation of choosing to discard items that normalize to the same string
would avoid this problem, though it might break working code that relies
on sending multiple headers with differing case, so I think this would
be no better overall.)

Added file: http://bugs.python.org/file11886/issue2775.patch

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3647] urlparse - relative url parsing and joins to be RFC3986 compliance

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Hmm, I see you've already commented on some of those, Senthil.  Perhaps
you could add a comment to this bug explaining how your patch relates to
the others.  Should it replace them? (why?)  Should one of those patches
be applied also?

Also, my comment about there being agreement on python-dev is probably a
misrepresentation.  This is what I remembered, I think:

http://article.gmane.org/gmane.comp.python.devel/73314/

which seems to say that a new API should be added, but not that urlparse
shouldn't be changed to be more compliant with RFC 3986.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3647>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3647] urlparse - relative url parsing and joins to be RFC3986 compliance

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Here they are:

http://bugs.python.org/issue1500504
http://bugs.python.org/issue1462525
http://bugs.python.org/issue1591035

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3647>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3647] urlparse - relative url parsing and joins to be RFC3986 compliance

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

There are a bunch of other candidate implementations of this RFC kicking
around, I think.

Also, I believe there was agreement on python-dev that a new module
should be added rather than changing the behaviour of module urlparse.

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3647>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2007] cookielib lacks FileCookieJar class for Internet Explorer

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Forgot to add: if somebody else does the work, I'm happy to agree to the
code being used in Python stdlib.  Perhaps it would be necessary to get
the author of the original Perl code from which this MSIE class is
derived to sign a contributor agreement, though (even though he already
agreed to a BSD-ish license).

FWIW, there's also a Firefox 3 cookies.sqlite cookiejar in the same
package (though not yet used in anger by me, and wanting more tests, so
marked experimental).

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2007>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3924] cookielib chokes on non-integer cookie version, should ignore it instead

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

The sensible fix for this is to strip the quotes off, defaulting to
version 0 on failure to parse the version cookie-attribute.  It's not
necessary to retain the original version string.

By the way, what you posted warning rather than a strictly unhandled
exception or "crash" -- it's a bug, but won't cause the program to stop.
 And by "none of the cookies work after that", you mean that no cookies
in headers containing the quoted version cookie-attribute are accepted
by the cookiejar.

FWIW, this bug only affects RFC 2109 cookies, not RFC 2965 cookies.

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3924>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3704] cookielib doesn't handle URLs with / in parameters

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Do we have an RFC 3986 URI parser in the stdlib now?  It would be better
to use that if so, but I don't see one.  Failing that, an implementation
of the relevant part of that RFC is only about four lines of code, so
that would be better than naively looking for "?" (request_path should
probably be changed at the same time).

I'll try and add a patch that does that and check what Firefox does to
see if I agree it's a bug.

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4131] Note that Firefox 3 does not write cookies.txt

[John J Lee]

New submission from John J Lee <[EMAIL PROTECTED]>:

Just adds a note to the cookielib documentation to point out that
Firefox 3 no longer writes cookies.txt, the file format understood by
cookielib.MozillaCookieJar (firefox now maintains persistent cookie
state in an sqlite database).

--
assignee: georg.brandl
components: Documentation
files: firefox3_cookies_txt.patch
keywords: patch
messages: 74823
nosy: georg.brandl, jjlee
severity: normal
status: open
title: Note that Firefox 3 does not write cookies.txt
Added file: http://bugs.python.org/file11806/firefox3_cookies_txt.patch

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4131>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2190] MozillaCookieJar ignore HttpOnly cookies

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

I think firefox 3 no longer writes cookies.txt (it writes cookies.sqlite
instead).

Can anybody point out a version of firefox that wrote this HttpOnly
information to cookies.txt, so the patch can be tested?

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2190>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1570255] redirected cookies

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Sorry I turned up rather late here (is there a way to subscribe to
changes to all bugs whose comments or title contain a given string?)

If it works with Firefox and not with cookielib it's almost certainly a
bug.  However, it's not clear to me from the report what the real bug
might be, because cookies aren't really redirected -- they're just added
to the new request following the usual rules for adding Cookie: headers
to requests.  That's why the redirect handler deliberately doesn't add
the unredirected headers -- the Cookie header gets added later on, by
HTTPCookieProcessor.  So, a diagnosis of the problem would involve
finding out why cookielib thinks that your cookie should not be returned
to the server in the request in question (which just happens to be a
redirected request).  Running your script with cookielib's logging
enabled (see the documentation) will probably be all that's required to
find that out; if you can still reproduce this, please post the log here
(sanitized to remove usernames, passwords, etc.).  If not, a test case,
or failing that a sanitized dump of the HTTP traffic, would be very useful.

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1570255>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2007] cookielib lacks FileCookieJar class for Internet Explorer

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Note that the code on wwwsearch.sf.net only reads cookies, and does not
write them.  Also, the approach used is fragile to changes to MS's
"index.dat" database, which was the reason why that code was not
included when cookielib was added.  As far as I know, the index.dat
format is not specified and is subject to change or removal by MS.  It's
possible that that MSIE cookiejar is already broken on Windows Vista,
for example, since I have never tested it on that platform.

An alternative approach that should allow writing cookies would be to
use InternetGetCookie / InternetSetCookie API:

http://msdn.microsoft.com/en-us/library/aa384710(VS.85).aspx

A *sketch* of that approach (which I'm not going to implement properly)
is here:

http://codespeak.net/svn/wwwsearch/mechanize/trunk/attic/MSIEDBCookieJar.py

The other, fragile (but working, at least on some MS OSes) approach:

http://codespeak.net/svn/wwwsearch/mechanize/trunk/mechanize/_msiecookiejar.py

--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2007>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1028088] Cookies without values are silently ignored (by design?)

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

The Cookie: header does not have a "secure flag" (The Set-Cookie: header
does).

I don't strongly object to the issue identified in the original comment
being fixed.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1028088>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1028088] Cookies without values are silently ignored (by design?)

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

I was responding to your comment of 2008-10-08 03:08, not to the opening
comment.  I already responded to the opening comment.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1028088>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1028088] Cookies without values are silently ignored (by design?)

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

You haven't said what the specific problem is.  Note that the
SimpleCookie class really represents a set of cookies, and the Morsel
class represents a single cookie.  It seems that setting special
value-less cookie-attributes like "secure" works:

Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Cookie
>>> c = Cookie.SimpleCookie("spam=eggs; foo=bar")
>>> c.output()
'Set-Cookie: foo=bar\r\nSet-Cookie: spam=eggs'
>>> c["foo"]["secure"] = 1
>>> c.output()
'Set-Cookie: foo=bar; secure\r\nSet-Cookie: spam=eggs'

HttpOnly support was added here:

http://bugs.python.org/issue1638033

However, I don't know why BaseCookie.load() treats "secure" or
"HttpOnly" specially at all -- those names are not special in Cookie:
heders.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1028088>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2190] MozillaCookieJar ignore HttpOnly cookies

[John J Lee]

Changes by John J Lee <[EMAIL PROTECTED]>:


--
nosy: +jjlee

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2190>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3858] make install tries to install files outside of --prefix

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

OK, this was because I had a .pydistutils.cfg file containing the
following (ironically, put there following somebody's recipe for
installing setuptools packages using stow):

[install]
install_lib=~/lib/python$py_version_short/site-packages
install_scripts=~/bin
 
[easy_install]
site_dirs=~/lib/python$py_version_short/site-packages

Removing that file, make install no longer tries to install files
outside of the directory passed to --prefix

So this bug is not valid, and I don't think there's any regression.

There's probably another bug about making it awkward to invent a
consistent way of installing Python software using tools like stow, but
I'm not sure whether that bug lies with Python or with setuptools, or both.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3858>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3858] make install tries to install files outside of --prefix

[John J Lee]

New submission from John J Lee <[EMAIL PROTECTED]>:

./configure --prefix=DIR && make && make install tries to install files
in directories outside of DIR.  This happens both with trunk (r66412)
and 2.6b3.  This is a problem for users of GNU stow, for example.  I
know that certainly this worked fairly recently on the py3k branch, for
example, and I believe it also used to work on trunk.

I'm not certain whether in this particular run the --prefix directory
existed or not prior to make install, but I certainly get essentially
the same failure regardless of whether that directory exists.

~/src/Python-2.6b3$ ./configure  --prefix=/home/john/stow/python26b3
...
~/src/Python-2.6b3$ make
...
~/src/Python-2.6b3$ make install
/usr/bin/install -c python-config
/home/john/stow/python26b3/bin/python2.6-config
rm python-config
./python -E ./setup.py install \
--prefix=/home/john/stow/python26b3 \
--install-scripts=/home/john/stow/python26b3/bin \

--install-platlib=/home/john/stow/python26b3/lib/python2.6/lib-dynload \
--root=/
running install
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers

Failed to find the necessary bits to build these modules:
_bsddb _tkinter   bsddb185
dbmgdbm   sunaudiodev 
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.

running build_scripts
running install_lib
copying build/lib.linux-i686-2.6/_random.so ->
/home/john/lib/python2.6/site-packages
error: could not delete
'/home/john/lib/python2.6/site-packages/_random.so': Permission denied
make: *** [sharedinstall] Error 1

--
messages: 73175
nosy: jjlee
severity: normal
status: open
title: make install tries to install files outside of --prefix

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3858>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3577] Interpreter name: python vs. python-3.0

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

"make install" actually installs as "python3.0" (and not as
"python-3.0", nor "python3", nor "python").

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3577>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3577] Interpreter name: python vs. python-3.0

[John J Lee]

New submission from John J Lee <[EMAIL PROTECTED]>:

The tutorial says:

"The Python interpreter is usually installed as /usr/local/bin/python on
those machines where it is available"

Shouldn't that be "python3" or "python-3.0"?  And the same throughout
the rest of the tutorial?

make install seems to think that Python 3 should not be installed as
"python", and should be installed as "python-3.0".

--
assignee: georg.brandl
components: Documentation
messages: 71268
nosy: georg.brandl, jjlee
severity: normal
status: open
title: Interpreter name: python vs. python-3.0
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3577>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

By the way, this is a feature addition, not a bug fix.  The first beta
releases for 2.6 and 3.0 came out some time ago, so according to PEP
361, this change should not be committed to trunk until after the 2.6 /
3.0 maintenance branches have been created.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

The CaseInsensitive dict class fails to preserve its invariants (implied
invariants, since there are no tests for it).  There are also problems
with the documentation in the patch.  I will submit a modified patch, I
hope later this week.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Of course, that "along the lines of" suggestion isn't quite right: None
does not have a .title() method.

(and, to spell it out, I'm assuming in that suggestion that .headers is
the dict of headers with .capitalize()d keys, i.e. unchanged from Python
2.5)

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

> With respect to point 1), I assume that we all agree upon that headers
> should stored in Titled-Format instead of Capitalized-format. 

I would probably choose to store the headers in Capitalized-form,
because that makes implementing .headers trivial.

[...]
> Now, if we go for a Case Normalization at the much later stage, will the
> headers be stored still in capitalize() format? ( In that case, this bug
> requests it be stored in .titled() format confirming to many practices)
> Would you like to explain a bit more on that?

Implement .get_header() and friends using .headers, along the lines of:

def get_header(self, header_name, default=None):
return self.headers.get(
header_name,
self.unredirected_hdrs.get(header_name, default)).title()

And then ensure that the headers actually passed to httplib also get
.title()-cased.  This also has the benefit, compared with your patch, of
leaving the behaviour of non-HTTP URL schemes unchanged.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Just to quickly note that by "providing case-insensitive lookup" I don't
necessarily mean via .headers.  But it's you who's providing the patch,
so I'll wait for your next suggestion rather than discuss how I might
change the code.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

> > * The patch to the docs seems to muddy the waters even further (than the
> > current slightly murky state) about whether and why .headers is to be
> > preferred over the methods, or vice-versa.  I think .headers should
> > remain undocumented, for the reason stated by the doctest that failed
> > with Hans-Peter's original patch.
> 
> IIRC, Hans-Peter's comment was on the reference to .headers
undocumented interface mentioned in the test_urllib2.

I made no reference to Hans-Peter's comment -- only to his patch, so I
don't know what you're getting at here.  Could you respond to my
comment, please?

> >  The best course of action is
> > debatable, but the patch is a regression in this respect, so should not
> > be committed as-is.
> 
> My understanding in this case was to address 1) Title()-ize the
headers and 2)
> provide a case insensitive lookup.

Can you explain why you think providing case-insensitive lookup requires
documenting .headers?


> Is this sufficient now to expose the headers method? If not, what else?
> If headers method should not be exposed, then will the 2 cases
addressed above
> still do, as this issue request was opened for that?

There is no method named "headers".  I think that the .headers attribute
should never be documented, because it does not contain the
"unredirected headers".  Changing that behaviour would break code,
further confuse matters and complicate writing code that works with
multiple versions of Python.  A case *could* be made for changing it (by
including the "unredirected headers"), because other code will have been
broken by the introduction of .unredirected_hdrs; I prefer instead to
stick with old breakage rather than swapping it for new breakage, but as
I say, the best course of action is debatable.  Another choice would be
to start the process of deprecating .headers, and introduce a new
attribute with a similar function.  As long as your chosen solution
isn't actually a step backwards or sharply sideways, I probably won't
object very strongly.  What isn't really debatable is that the patch
makes things worse here: it adds a newly-documented interface which is
subtly and surprisingly different from the other one (an unacceptable
change in itself, IMO) without even explaining the difference between
the two, why they are different, and why one would want to use or avoid
one or other interface.

There are other problems with the documentation patch, but there's no
point in discussing those until the changes are agreed on.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

There already is a test for the breakage, but the patch changes the
expected output to match the new return value of .header_items():

-[('Foo-bar', 'baz'), ('Spam-eggs', 'blah')]
+[('Foo-Bar', 'baz'), ('Spam-Eggs', 'blah')]

Code that previously worked fine, for example code that iterates through
.header_items() and does string comparisons on the header names, or does
"in" tests on the keys of dict(header_items), etc. will break, the
existence of .has_header() notwithstanding.

What is the purpose of this change?  Can you explain how that justifies
breaking working code?

The alternative to this change is to leave the return value of
.header_items() unchanged.  That could be done by performing case
normalisation at a later stage.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

* The patch looks like it will break code that uses .header_items(),
which is not acceptable.

* The patch to the docs seems to muddy the waters even further (than the
current slightly murky state) about whether and why .headers is to be
preferred over the methods, or vice-versa.  I think .headers should
remain undocumented, for the reason stated by the doctest that failed
with Hans-Peter's original patch.  The best course of action is
debatable, but the patch is a regression in this respect, so should not
be committed as-is.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2451] No way to disable socket timeouts in httplib, etc.

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Facundo, are you going to review this?

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2451>
__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2451] No way to disable socket timeouts in httplib, etc.

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Me:

"""
This should be done in such a way as to also fix the lack of
documentation of the None special value in the protocol modules
documentation (httplib, etc.).  I should have fixed that as part of this
patch, but ran out of time -- sorry!
"""

Erm, possibly the meaning and allowed values of the timeout arguments
would be more naturally documented by pointing to the socket
.settimeout() method docs, actually.

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2451>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2451] No way to disable socket timeouts in httplib, etc.

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Should I also have selected "Python 3.0" from the "Versions" list, BTW?
 Don't know what the proper process is ATM...

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2451>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2451] No way to disable socket timeouts in httplib, etc.

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

I've attached a patch.

My patch introduces one minor issue: it's an inconvenience when wrapping
objects if special default values like socket._GLOBAL_DEFAULT_TIMEOUT
are not public.  However, I think it's not worth making that special
value public in this case, because it's not needed by code that does not
support the socket.getdefaulttimeout() global default timeout.


Patch description
-

 * Change the timeout arguments that were introduced with Facundo's 2.6
timeout changes so that they have the same meaning as the argument of
socket.socket.settimeout() .  Specifically, None means "no timeout"
(previously, there was no way to request that), and there is no special
public timeout value meaning "use the global default
socket.getdefaulttimeout() value" (previously, you could pass None to
request that).  This affects socket, urllib2, urllib (only
urllib.ftpwrapper, for urllib2's benefit, urllib public interface and
behaviour is unchanged), httplib, ftplib, telnetlib, poplib, and smtplib.

 * Fix a test bug: test_urllib2net changed global state by calling
urllib2.install_opener(), which interfered with other tests.

 * In tests, where possible, close sockets by calling high-level methods
(e.g. call ftplib.FTP.close(), rather than poking into the object's
internals to .close() the socket directly).

 * Inconsistent defaulting behaviour in telnetlib was introduced with
the timeout changes (r54608).  Made timeout behave like port in terms of
defaulting behaviour.

 * Improve socket.create_connection() documentation.  Some of these
changes need to be propagated to the individual protocol modules that
call this function (e.g. httplib).

  - Document return value

  - Be more PEP 8-compliant ("Connect to...", not "Connects to...")

  - Remove this sentence, since it seems out of place in API
documentation and unlikely to be true: "Especially useful for
higher-level protocols, it is not normally used directly from
application-level code."

  - Reword to remove any doubt that the timeout applies to (almost) all
blocking operations, not just .connect()

  - Rephrase timeout parameter description for better English style.

  - Note that create_connection() is a convenience function (rather than
part of the thin wrapper around the C API).

  - Make the docstring for create_connection() match the official reST
API docs.


Unresolved issues with the new 2.6 timeout functionality


 * http://bugs.python.org/issue2452

 * I did not propagate the changes to socket.create_connection() docs to
all the protocol modules (httplib, etc.).  Probably this change should
be committed separately -- I ran out of time.

 * References in the docs to "the global default timeout setting" are
vague.  They should specifically refer to socket.getdefaulttimeout() . 
This should be done in such a way as to also fix the lack of
documentation of the None special value in the protocol modules
documentation (httplib, etc.).  I should have fixed that as part of this
patch, but ran out of time -- sorry!

 * Inconsistency: CacheFTPHandler has per-handler timeout, per-request
timeout is ignored!  Doc/library/urllib2.rst says (in two places):

"""This actually only work for HTTP, HTTPS, FTP and FTPS connections."""

That's not true. (What about CacheFTPHandler, for instance?)  It's also
unclear why it refers to *connections* rather than URL schemes, handler
classes, and the network operations they perform.  (there's also a
little grammatical error here -- s/work/works/)

 * API weirdness: Only some, special, urllib2.Request objects may be
passed to handlers, because the constructor does not create objects with
a .timeout.  Should it really be per-request anyway (I'm not sure)?

--
keywords: +patch
Added file: http://bugs.python.org/file9902/issue2451.patch

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2451>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

urllib2.Request.headers is, in practice, an undocumented public
interface.  Did you run the tests?  There is room for improvement here,
but not in the way you suggest.

python[1]$ python2.6
iPython 2.6a1+ (trunk:62045M, Mar 30 2008, 03:07:23) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import test.test_urllib2
>>> print test.test_urllib2.test_request_headers_dict.__doc__

The Request.headers dictionary is not a documented interface.  It should
stay that way, because the complete set of headers are only accessible
through the .get_header(), .has_header(), .header_items() interface.
However, .headers pre-dates those methods, and so real code will be
using
the dictionary.

The introduction in 2.4 of those methods was a mistake for the same
reason:
code that previously saw all (urllib2 user)-provided headers in .headers
now sees only a subset (and the function interface is ugly and
incomplete).
A better change would have been to replace .headers dict with a dict
subclass (or UserDict.DictMixin instance?)  that preserved the .headers
interface and also provided access to the "unredirected" headers.  It's
probably too late to fix that, though.


Check .capitalize() case normalization:

>>> url = "http://example.com";
>>> Request(url, headers={"Spam-eggs": "blah"}).headers["Spam-eggs"]
'blah'
>>> Request(url, headers={"spam-EggS": "blah"}).headers["Spam-eggs"]
'blah'

Currently, Request(url, "Spam-eggs").headers["Spam-Eggs"] raises
KeyError,
but that could be changed in future.


>>>

--
nosy: +jjlee

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] urllib2 header capitalization

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Specifically, these improvements could be made:

 * the headers actually sent to httplib could be normalized to
Standard-Http-Case by urllib2
 * the urllib2.Request.headers interface could support case-insensitive
key lookup

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2275>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2451] No way to disable socket timeouts in httplib, etc.

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Great.  I'll try to submit a patch this weekend.

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2451>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2450] urllib2.Request constructor has no timeout parameter

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

I don't buy the "API complication" argument.

I might accept an argument that the timeout isn't really anything to do
with the request, so I won't bother to continue with this bug report.

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2450>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2450] urllib2.Request constructor has no timeout parameter

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

This should be solved by introducing a "not set" value other than None.

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2450>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2451] No way to disable socket timeouts in httplib, etc.

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

I see this thread:

http://www.gossamer-threads.com/lists/python/dev/552292

But I don't see an explanation of this API decision there that I understand.

*Because* socket.setdefaulttimeout() is a hack for when nothing else is
available, there should be a way to avoid that global state.

You say that "Now that you can pass the timeout when creating the
connection, you shouldn't use the default setting.".  That's true, for
new code, and for code is able to immediately change -- indeed, that
always has been true.  Code exists that makes use of
socket.setdefaulttimeout(), or requires use of it in order to set a
timeout.  Can you explain why this state of affairs makes it necessary
to force this global state on users of httplib?

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2451>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2452] inaccuracy in httplib timeout documentation

[John J Lee]

John J Lee <[EMAIL PROTECTED]> added the comment:

Oops, un-finished sentence in my opening comment ("In fact, other
non-blocking.") should have read:

In fact, other blocking operations will also time out.

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2452>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2452] inaccuracy in httplib timeout documentation

[John J Lee]

New submission from John J Lee <[EMAIL PROTECTED]>:

The documentation for the new timeout support in 2.6 states that "If the
optional timeout parameter is given, connection attempts will timeout
after that many seconds".  In fact, other non-blocking.  The only
operation that might block for longer than the requested timeout is the
getaddrinfo() in socket.create_connection().

There may be similar inaccuracies in the docs of other modules to which
timeout support was added.

--
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 64295
nosy: georg.brandl, jjlee
severity: normal
status: open
title: inaccuracy in httplib timeout documentation
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2452>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2451] No way to disable socket timeouts in httplib, etc.

[John J Lee]

New submission from John J Lee <[EMAIL PROTECTED]>:

The new timeout support in 2.6 makes use of new function
socket.create_connection().  socket.create_connection() provides no way
to disable timeouts, other than by relying on socket.getdefaulttimeout()
returning None.  This is unfortunate, because it was the purpose of the
new timeout support to allow control of timeouts without reliance on
global state.

setdefaultsocket.create_connection() should always call
sock.settimeout() with the timeout passed to create_connection(), unless
a special non-None value is passed indicating that the global default is
to be used.  Specific modules may then use that special non-None value
where required, to preserve backwards-compatibility.

--
components: Library (Lib)
messages: 64293
nosy: jjlee
severity: normal
status: open
title: No way to disable socket timeouts in httplib, etc.
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2451>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2450] urllib2.Request constructor has no timeout parameter

[John J Lee]

New submission from John J Lee <[EMAIL PROTECTED]>:

r55792 added timeout support to urllib2.  A timeout parameter was added
to urllib2.OpenerDirector.open(), but there is no corresponding Request
constructor parameter.  timeout is unique in that respect.  Instead,
OpenerDirector.open() sets req.timeout on request instances.  The
parameter "timeout" should behave in the same way as existing parameter
"data".

--
components: Library (Lib)
messages: 64291
nosy: jjlee
severity: normal
status: open
title: urllib2.Request constructor has no timeout parameter
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2450>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com