Change by And Clover :
--
pull_requests: +18309
pull_request: https://github.com/python/cpython/pull/18959
___
Python tracker
<https://bugs.python.org/issue39
Change by And Clover :
--
keywords: +patch
pull_requests: +18136
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18780
___
Python tracker
<https://bugs.python.org/issu
And Clover added the comment:
Yep, should be straightforward to fix (though not to test, as fifty-day test
cases tend to be frowned upon...)
--
___
Python tracker
<https://bugs.python.org/issue39
New submission from And Clover :
Since bpo-15038, waiting to acquire locks/events/etc from _thread/threading on
Windows can fail to return long past the requested timeout. Cause:
https://github.com/python/cpython/blob/3.8/Python/thread_nt.h#L85
using 32-bit GetTickCount/DWORD, which
And Clover added the comment:
> Are you saying there is no (http) RFC compliant way to fix this
Sadly, yes.
And though RFCs aren't always a fair representation of real-world use, RFC 7578
is informative as well as normative: at present nothing produces "filename*="
in multip
And Clover added the comment:
HTTP generally isn't an RFC 822-family standard. Its headers look a lot like
it, but they have their own defined syntax that differs in niggling little
details. Using mail parsing code for HTTP isn't usually the right thing.
HTTP has always used its own syntax
And Clover added the comment:
Attempting to answer the question "did this open call fail because the path was
a directory" by implication from "do we think we ought to be able to write a
file to this directory" is IMO doomed. There's no reliable way to determine
whethe
And Clover added the comment:
This is CVE-2016-0772 and appears to have been fixed properly with an exception
here:
https://hg.python.org/cpython/rev/d590114c2394 (py3)
https://hg.python.org/cpython/rev/b3ce713fb9be (py2)
--
resolution: -> fixed
status: open ->
Andrew Clover added the comment:
> Why only PATH_INFO is encoded in such a manner, but QUERY_STRING is passed
> without any changes and does not requires any latin-1 to utf-8 recodings?
Laziness: QUERY_STRING should be pure-ASCII, making any such transcoding a
no-op.
In principle
New submission from And Clover:
When an SMTP server responds to the STARTTLS command with an error, the
smtplib.SMTP.starttls() method does not raise an exception, as it would if TLS
negotiation itself failed. Consequently naïve callers of the function may
assume that a TLS connection has
And Clover added the comment:
This could potentially be considered a security issue as it would allow a MitM
attacker to sabotage the STARTTLS and get the rest of the content in the clear.
I don't personally consider it too serious as I doubt anyone is (a) relying on
the security
And Clover added the comment:
(This issue should be closed; it is superseded by the fix for 10155 in Python
3.2.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9022
And Clover added the comment:
(belated close-fixed)
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10155
And Clover added the comment:
WSGI's usage of ISO-8859-1 for all HTTP-byte-originated strings is very much
deliberate; we needed a way to preserve the original input bytes whilst still
using unicode strings, and at the time surrogateescape was not available. The
result is counter-intuitive
And Clover a...@doxdesk.com added the comment:
@carsten.klein: there is no such thing as an “original RFC”. The RFCs that have
been produced on the subject of cookies, 2109 and 2965, were drawn up long
after user-agents implemented cookies. Their attempts to clean up the warts of
cookies
And Clover a...@doxdesk.com added the comment:
No, not specifically. My patch is conservative about what variables it recodes,
yours more liberal, but it's difficult to say which is the better approach, or
what PEP requires.
If you're happy with the current patch, go ahead, let's have
Changes by And Clover a...@doxdesk.com:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10490
___
___
Python-bugs-list mailing
New submission from And Clover a...@doxdesk.com:
The `enum_types` function in `MimeTypes.read_windows_registry` tries to
`.encode` the results of `EnumKey`, assuming it to be a Unicode string.
However, `_winreg.EnumKey` in Python 2.x actually returns a byte string
(straight from the ANSI
Changes by And Clover a...@doxdesk.com:
Removed file: http://bugs.python.org/file19745/mimetypes-patch2-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10490
Changes by And Clover a...@doxdesk.com:
Added file: http://bugs.python.org/file19746/mimetypes-patch2-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10490
And Clover a...@doxdesk.com added the comment:
Thanks.
Some of those additions in _needs_transcode are potentially controversial,
though. I'm not wholly sure it's the right thing to transcode these.
Some of them may not actually come from the request, eg `REMOTE_USER` may be
filled
Changes by And Clover a...@doxdesk.com:
Removed file: http://bugs.python.org/file19303/wsgiref-patches-3.2a3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10155
And Clover a...@doxdesk.com added the comment:
Ah, sorry, submitted wrong patch against 3.2, disregard. Here's the 'proper'
version (the functionality isn't changed, just the former patch had an unused
and-Falsed out clause for reading environb, which in the end I decided not to
use
And Clover a...@doxdesk.com added the comment:
The various attempts by RFCs to codify HTTP cookies are useless and bear no
resemblance to what browsers actually do.
In the real world, every byte in the range 0x20-0x7E is allowed, except for the
semicolon, the equals (in names), and in Opera
And Clover a...@doxdesk.com added the comment:
Yes, CGIHandler is broken in 3.0-3.1; wsgiref in general has been in limbo
until the whole issue of py3k-WSGI is sorted. This seems to be happening now in
PEP .
Attached patch to make CGIHandler use the byte interfaces for stdin/stdout
New submission from And Clover a...@doxdesk.com:
Currently wsgiref's CGIHandler makes a WSGI environ from the CGI environ
without changes.
Unfortunately the CGI environ is wrong in a number of common circumstances:
- on Windows, the native environ is Unicode, and different servers choose
And Clover a...@doxdesk.com added the comment:
(patch for Python 2.x, for what it's worth)
--
Added file: http://bugs.python.org/file19304/wsgiref-patches-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10155
And Clover a...@doxdesk.com added the comment:
(same again for branch PJ Eby's wsgiref svn: same as previous 2.7 patch aside
from the line numbers)
--
Added file: http://bugs.python.org/file19309/wsgiref-patches-eby2692.patch
___
Python tracker rep
New submission from And Clover a...@doxdesk.com:
It is relatively common to have keys in the HKEY_CLASSES_ROOT MIME database
that are not readable to all users, typically written by third-party
applications. (My WinXP test box has a dozen, for apps like Flash, Silverlight
and Java
And Clover a...@doxdesk.com added the comment:
(same against 2.7 branch)
--
Added file: http://bugs.python.org/file19315/mimetypes-patch-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10162
And Clover a...@doxdesk.com added the comment:
The problem is that codecs.open() forces binary mode on the underlying
file object, and this defeats the U mode.
Actually the problem is it doesn't defeat it!
The function is documented to force binary, but it actually only does
mode = mode + 'b
And Clover [EMAIL PROTECTED] added the comment:
I would like to see something along the general lines of bmiller's patch
for dict views in a 3.x release... there are probably other iterators
that could do with chattier reprs also. (Range, on the other hand, is
fine as it is.)
It's not just
32 matches
Mail list logo
