Matt Eaton <agnostic...@gmail.com> added the comment:
Wanted to check in on this to see if there was any feedback on this topic?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Matt Eaton <agnostic...@gmail.com> added the comment:
Wanted to check in on this to see if there was any feedback by any community or
core members?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Matt Eaton <agnostic...@gmail.com> added the comment:
Adding some core team members to the nosy list to get their take on this as
well.
--
nosy: +berker.peksag, eric.smith
___
Python tracker <rep...@bugs.python.org>
<https://
Matt Eaton <agnostic...@gmail.com> added the comment:
I was able to get some time together today and created a rough draft for the
idea that you had Berker on introducing a new API with more strict parsing
rules.
This will allow the ValueError to be raised when the URL is parsed rathe
Matt Eaton <agnostic...@gmail.com> added the comment:
I agree with you in regards to the statement, "Apache's redirect can be turned
off, whereas this can't." That is why my first thought would be to try and
control this response to the client a bit better by providing a v
Matt Eaton <agnostic...@gmail.com> added the comment:
It looks like the 301 redirect is in place to emulate the behavior that Apache
provides when it runs into a trailing slash. This is observed when this
condition is met:
parts = urllib.parse.urlsplit(self.path)
if not parts.path.en
Matt Eaton <agnostic...@gmail.com> added the comment:
Oliver,
A possible option that would work for both the client side caching and the
server would be to pass back a Cache-Control header with a max-age attached
when the 301 is returned.
I am thinking something like this:
if os.path
Change by Matt Eaton <agnostic...@gmail.com>:
--
keywords: +patch
pull_requests: +6014
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Matt Eaton <agnostic...@gmail.com>:
A recent patch that I worked on resulted in an agreement that there could be a
use case for a new URL API to be added to urllib.parse. See:
https://bugs.python.org/issue33034
In my research to develop this new API I have been l
Matt Eaton <agnostic...@gmail.com> added the comment:
Berker and Eric, thank you very much. I really like the idea of introducing a
new API with more strict parsing rules for this situation. I would be willing
to put some ideas down on a firs
Matt Eaton <agnostic...@gmail.com> added the comment:
Eric, what is needed to try and reproduce this issue accurately? Would it be
installing websockets and setting up your client to ping to the server forever
(12 hours in this case)? If you are able to provide a client I would be
w
Matt Eaton <agnostic...@gmail.com> added the comment:
Yes, my goal for the patch was to provide a more explicit error message for
this situation and to provide a low surface area change to the overall source,
knowing that there are future development goals and backward compatibility to
Matt Eaton <agnostic...@gmail.com> added the comment:
This is a very good point, Eric. For backwards compatibility we would have to
set the default parameter to false, so we be in the same state we are today by
default. Knowing this my vote would be to go with the improv
Matt Eaton <agnostic...@gmail.com> added the comment:
One more question I would raise based upon a point made earlier by Eric is if
option C would be too large of a change for 3.8? Any thoughts on this?
--
___
Python tracker <rep...@bugs.p
Matt Eaton <agnostic...@gmail.com> added the comment:
Jonathan, thank you very much for your thoughts I appreciate the pros and cons
of each option.
In regards to your option C, if we provided a flag to optionally raise the
error in urlsplit and urlparse were you thinking the defaul
Matt Eaton <agnostic...@gmail.com> added the comment:
"Wouldn't we be better off to catch this error at parse time, instead of just
improve the error message when .port is called?"
I think there could be a case to be made about catching and dealing with this
error in urlpa
Matt Eaton <agnostic...@gmail.com> added the comment:
I agree. I think an explicit exception message would be appropriate when the
cast fails to cast from string to int in int(post, 10).
Putting in a PR to fix this now.
https://github.com/python/cpython/pull/6078
-
Change by Matt Eaton <agnostic...@gmail.com>:
--
pull_requests: +5838
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33034>
___
_
Change by Matt Eaton <agnostic...@gmail.com>:
--
keywords: +patch
pull_requests: +5837
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Matt Eaton <agnostic...@gmail.com> added the comment:
Thank you very much, Berker!!
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Matt Eaton <agnostic...@gmail.com>:
--
keywords: +patch
pull_requests: +5826
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Matt Eaton <agnostic...@gmail.com>:
I was reading through the SSL documentation and noticed a typo on Diffe-Hellman
and wanted to clean it up.
PR is coming soon.
--
assignee: docs@python
components: Documentation
messages: 313559
nosy: agnosticdev, docs@
Matt Eaton <agnostic...@gmail.com> added the comment:
Using Ubuntu 16.04 with the 3.6.0 tag I was also able to reproduce the same
error reported:
import socket
h =
"0123456789012345678901234567890123456789012345678901234567890123.example.com"
socket.gethostbyname(h)
Traceb
23 matches
Mail list logo
