[issue33034] urllib.parse.urlparse and urlsplit not raising ValueError for bad port
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.org/issue33034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33181] SimpleHTTPRequestHandler shouldn't redirect to directories with code 301
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.org/issue33181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33181] SimpleHTTPRequestHandler shouldn't redirect to directories with code 301
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://bugs.python.org/issue33181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33034] urllib.parse.urlparse and urlsplit not raising ValueError for bad port
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 rather than when the computed property is used. Jonathan, this will help address your concern on the consistency of when the error message is raised. I added the rough draft on my Github account here: https://github.com/agnosticdev/cpython-apis/tree/master/url https://github.com/agnosticdev/cpython-apis/blob/master/url/url.py Please take a look and let me know what you think. You can contact me directly to continue the conversation at my email: agnostic...@gmail.com -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33181] SimpleHTTPRequestHandler shouldn't redirect to directories with code 301
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 variable
max-age.
self.send_header("Cache-Control", "max-age=xxx")
Removing the condition completely would be good idea as well, but would be my
second course of action due to this functionality being in the Python code base
for awhile now.
if os.path.isdir(path):
for index in "index.html", "index.htm":
index = os.path.join(path, index)
if os.path.exists(index):
path = index
break
Those are my thoughts on the matter at least, possibly someone else in the
community could weigh in as well?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33181>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33181] SimpleHTTPRequestHandler shouldn't redirect to directories with code 301
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.endswith('/'):
Apache Directory Index Redirect:
http://httpd.apache.org/docs/current/mod/mod_dir.html#DirectoryIndexRedirect
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33181>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33181] SimpleHTTPRequestHandler shouldn't redirect to directories with code 301
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.isdir(path):
parts = urllib.parse.urlsplit(self.path)
if not parts.path.endswith('/'):
# redirect browser - doing basically what apache does
self.send_response(HTTPStatus.MOVED_PERMANENTLY)
new_parts = (parts[0], parts[1], parts[2] + '/',
parts[3], parts[4])
new_url = urllib.parse.urlunsplit(new_parts)
self.send_header("Location", new_url)
self.send_header("Cache-Control", "max-age=600")
self.end_headers()
return None
for index in "index.html", "index.htm":
index = os.path.join(path, index)
if os.path.exists(index):
path = index
break
Possibly we could even provide some way for the max age to be variable.
Thoughts?
--
nosy: +agnosticdev
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33181>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33167] RFC Documentation Updates to urllib.parse.rst
Change by Matt Eaton <agnostic...@gmail.com>: -- keywords: +patch pull_requests: +6014 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33167] RFC Documentation Updates to urllib.parse.rst
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 looking at the documentation for urllib.parse -https://docs.python.org/3/library/urllib.parse.html and thought that the descriptions for the RFC documents could use an update to better reflect the meaning of the document. -- assignee: docs@python components: Documentation messages: 314584 nosy: agnosticdev, docs@python priority: normal severity: normal status: open title: RFC Documentation Updates to urllib.parse.rst versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33034] urllib.parse.urlparse and urlsplit not raising ValueError for bad port
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 first pass at this. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33093] Fatal error on SSL transport
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 willing to setup a test case on my end. -- nosy: +agnosticdev ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33093> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33034] urllib.parse.urlparse and urlsplit not raising ValueError for bad port
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 keep in mind. That way the patch would be a first step in providing more explicit information when a developer would run into this situation and hopefully improving the current situation at hand. The new ValueError message raised in this patch does work for both urlparse and urlsplit. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33034] urllib.parse.urlparse and urlsplit not raising ValueError for bad port
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 improvements to the ValueError message when using .port as the current PR does now. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33034] urllib.parse.urlparse and urlsplit not raising ValueError for bad port
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.python.org> <https://bugs.python.org/issue33034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33034] urllib.parse.urlparse and urlsplit not raising ValueError for bad port
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 default flag to be set to True? For example: def urlparse(url, scheme='', allow_fragments=True, port_validation=True): def urlsplit(url, scheme='', allow_fragments=True, port_validation=True): -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33034] urllib.parse.urlparse and urlsplit not raising ValueError for bad port
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 urlparse() / urlsplit() instead of displaying an error when port property is used. I think that approaching it this way would cut right to the problem and alleviate carrying around a potentially bad port value. However, if the port error was caught during parsing but the url, scheme, etc.. values were still valid, are we taking away something from the user by raising the error too soon? Just a thought. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33034] urllib.parse.urlparse and urlsplit not raising ValueError for bad port
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 -- nosy: +agnosticdev ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33034] urllib.parse.urlparse and urlsplit not raising ValueError for bad port
Change by Matt Eaton <agnostic...@gmail.com>: -- pull_requests: +5838 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33034] urllib.parse.urlparse and urlsplit not raising ValueError for bad port
Change by Matt Eaton <agnostic...@gmail.com>: -- keywords: +patch pull_requests: +5837 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33045] SSL Dcumentation Error
Matt Eaton <agnostic...@gmail.com> added the comment: Thank you very much, Berker!! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33045] SSL Dcumentation Error
Change by Matt Eaton <agnostic...@gmail.com>: -- keywords: +patch pull_requests: +5826 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33045] SSL Dcumentation Error
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@python priority: normal severity: normal status: open title: SSL Dcumentation Error type: enhancement versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32958] socket module calls with long host names can fail with idna codec error
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)
Traceback (most recent call last):
File
"/home/agnosticdev/Documents/code/python/python-dev/cpython-3_6_0/Lib/encodings/idna.py",
line 165, in encode
raise UnicodeError("label empty or too long")
UnicodeError: label empty or too long
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "host_test.py", line 8, in
socket.gethostbyname(h)
UnicodeError: encoding with 'idna' codec failed (UnicodeError: label empty or
too long)
It looks like the hostname being 64 characters long is the issue in that it
cannot be encoded. Thus falling into the UnicodeError being raised in idna.py:
# ASCII name: fast path
labels = result.split(b'.')
for label in labels[:-1]:
if not (0 < len(label) < 64):
raise UnicodeError("label empty or too long")
if len(labels[-1]) >= 64:
raise UnicodeError("label too long")
return result, len(input)
I did some work on this to try and resolve this, but ultimately it was not
worth committing so I wanted to report my findings.
--
nosy: +agnosticdev
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32958>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
