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 issu
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
sugg
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
sugg
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 i
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 tr
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 p
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,
John J Lee added the comment:
Why not?
--
___
Python tracker
<http://bugs.python.org/issue1520831>
___
___
Python-bugs-list mailing list
Unsubscribe:
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'
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 probabl
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/issue1660
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
John J Lee added the comment:
My patch should be applied.
--
___
Python tracker
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailing list
Unsub
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
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/issue2
John J Lee added the comment:
This is a duplicate of issue3924
--
nosy: +jjlee
___
Python tracker
<http://bugs.python.org/issue8975>
___
___
Python-bugs-list m
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
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
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 i
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/i
Changes by John J Lee :
Added file: http://bugs.python.org/file17285/issue3704.patch
___
Python tracker
<http://bugs.python.org/issue3704>
___
___
Python-bugs-list mailin
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'
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.
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: +
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
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 wou
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. Cac
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 use
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/issue1424
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
Changes by John J Lee :
--
nosy: -jjlee
___
Python tracker
<http://bugs.python.org/issue991266>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by John J Lee :
--
nosy: -jjlee
___
Python tracker
<http://bugs.python.org/issue1172011>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 mailin
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.or
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 trac
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
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/issu
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/iss
John J Lee added the comment:
Why?
___
Python tracker
<http://bugs.python.org/issue1660009>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/m
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
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.pytho
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 t
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.
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 eq
Changes by John J Lee <[EMAIL PROTECTED]>:
--
nosy: +facundobatista
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4079>
___
__
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
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
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).
__
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 <[EMAI
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_
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.pyt
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
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 PROTECTE
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 dige
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 ma
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 b
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
Adde
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 ha
Changes by John J Lee <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file11887/issue2775-problems.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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 th
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
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.pytho
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.
-
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
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
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
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 da
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
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
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 cookiel
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 trac
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.o
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 &qu
Changes by John J Lee <[EMAIL PROTECTED]>:
--
nosy: +jjlee
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2190>
___
___
Python-bugs
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/si
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
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 track
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 throughou
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 hav
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 thi
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
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 implement
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
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
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')]
+[('
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
John J Lee <[EMAIL PROTECTED]> added the comment:
Facundo, are you going to review this?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2451>
__
___
Python
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
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]&
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 maki
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
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
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>
__
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.
___
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://
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
avail
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]>
&
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
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 unfor
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(
1 - 100 of 102 matches
Mail list logo
