karl added the comment:
Just to note that there is a maintained list of officially accepted schemes at
IANA.
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
In addition there is a list of unofficial schemes on wikipedia
https://en.wikipedia.org/wiki/List_of_URI_schemes
New submission from karl :
A very simple HTTP server
#!/usr/bin/python3
import http.server
from os import chdir
# CONFIG
ROOTPATH = '/Your/path/'
PORT = 8000
# CODE
def run(server_class=http.server.HTTPServer,
server_handler=http.server.SimpleHTTPRequestHandler):
serv
New submission from karl :
The code has a set of old HTML templates. Here is a patch to change it to very
simple html5 templates.
--
components: Library (Lib)
files: server-html5.patch
keywords: patch
messages: 146641
nosy: karlcow, orsenthil
priority: normal
severity: normal
status
karl added the comment:
Ezio, Martin,
HTML 3.2, HTML 4.01 are not outdated. They have stable specifications. That
said their doctypes have not influence at all in browsers. The html5 doctype
has been chosen because it was the minimal string of characters
that put the browsers into strict
karl added the comment:
Yup. I doesn't bring anything except putting the output in line with the
reality of browsers implementations. You may close it. I don't mind.
--
___
Python tracker
<http://bugs.python.o
karl added the comment:
Eric,
Two possible solutions to explore:
Either the HEAD reports exactly the same thing than a GET without the body,
because it is the role of the GET, but that means indeed adding support for the
HEAD.
or creating a catch-all answer for all unknown or not
karl added the comment:
@Luke
did you have the opportunity to look at
http://greenbytes.de/tech/webdav/rfc6265.html
If there is something which doesn't match reality in that document that would
be cool to have feedback about it.
--
___
P
karl added the comment:
The source of 3.1/lib/python3.1/xml/dom/__init__.py is correct
===
minidom -- A simple implementation of the Level 1 DOM with namespace
support added (based on the Level 2 specification) and other
minor Level 2 functionality
karl added the comment:
This following markup creates the mistake as described earlier in the comments
This markup doesn't
It returns
When using this markup
It outputs the right markup,
So the mistake occurs really when xmlns="". I have checked an
karl added the comment:
The rules for parsing and setting the cookies are different. Server should
always produce strict cookies only. So the production rules are to be done
accordingly to the specification.
Adam Barth is working right now on an update of the "HTTP State Manag
karl added the comment:
Ah the server is back the rules for the User Agents are defined here
http://tools.ietf.org/html/draft-ietf-httpstate-cookie#section-5
--
___
Python tracker
<http://bugs.python.org/issue2
karl added the comment:
John: Ah sorry, if I misunderstood. The bug seems to say that it is about the
Cookie Name and legal chars for this cookie name. What I was trying to say is
that the processing of the Cookie Name is different depending if you are a
client or a server *and* that there
karl added the comment:
agreed. :)
Then my question about parsing rules for libraries. Is interoperability a plus
here.
--
___
Python tracker
<http://bugs.python.org/issue2
karl added the comment:
@aclover
see my comment http://bugs.python.org/issue2193#msg125423
Adam Barth is working for Google on Chrome.
The RFC being written is made in cooperation with other browser developers.
If you have comments about this RFC you are welcome to add comment on freenode
at
karl added the comment:
The current specification as of today documents
https://dom.spec.whatwg.org/#dom-document-createelementns
If you run this in the browser console,
var nsdoc = 'http://foo.bar/zoo';
var xmldoc = document.implementation.createDocument(nsdoc, 'Zoo&#
karl added the comment:
I created a PR following the recommendations of p-ganssle
https://github.com/python/cpython/pull/16507
--
nosy: +karlcow
___
Python tracker
<https://bugs.python.org/issue22
karl added the comment:
@zach.ware
@r.david.murray
So I was looking at that issue. There is a lot of work.
I had a couple of questions, because there are different categories
# Empty tests for existing functions.
This seems to be straightforward as they would complete the module
karl added the comment:
err… Errata on my previous comment.
"""
Simple implementation of the Level 1 DOM.
Namespaces and other minor Level 2 features are also supported.
"""
https://github.com/python/cpython/blob/c65119d5bfded03f80a9805889391b66fa7bf551/Lib/xm
karl added the comment:
@gaurav The pull request
https://github.com/python/cpython/pull/10870
has been closed in favor of
https://github.com/python/cpython/pull/15773
which has already been merged.
So we can probably close here.
--
message_count: 7.0 -> 8.0
nosy: +karl
karl added the comment:
Relevant spec
https://tools.ietf.org/html/rfc6265
--
nosy: +karlcow
___
Python tracker
<https://bugs.python.org/issue1375011>
___
___
New submission from karl :
by copy a large file e.g.
-rwxrwxr-x 1 1002 1001 5359338160 Feb 9 2019 xxx_file_xxx.mdx
copy2 / sendfile / fastcopy fails with:
Traceback (most recent call last):
File "/usr/lib/python3.8/multiprocessing/pool.py", line 125, in worker
result = (
karl added the comment:
could not reproduce the error
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Change by karl :
--
keywords: +patch
nosy: +karlcow
nosy_count: 2.0 -> 3.0
pull_requests: +22875
pull_request: https://github.com/python/cpython/pull/24034
___
Python tracker
<https://bugs.python.org/issu
karl added the comment:
@iritkatriel Github PR done.
https://github.com/python/cpython/pull/24034
--
___
Python tracker
<https://bugs.python.org/issue25
Change by karl :
--
nosy: +karlcow
nosy_count: 4.0 -> 5.0
pull_requests: +22878
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/24038
___
Python tracker
<https://bugs.python.org/
karl added the comment:
Converted into GitHub PR https://github.com/python/cpython/pull/24038
--
___
Python tracker
<https://bugs.python.org/issue4643>
___
___
karl added the comment:
> The getattr call here has a default value, so it should not raise
> AttributeError. It should also not raise any other exception because a valid
> implementation of __getattr__ should raise only AttributeError:
but probably the intent of the patch h
karl added the comment:
Ezio,
TL,DR: Testing in browsers and adding two tests for this issue.
Should I create a PR just for the tests?
https://github.com/python/cpython/blame/63298930fb531ba2bb4f23bc3b915dbf1e17e9e1/Lib/test/test_htmlparser.py#L479-L485
A: comma without spaces
Change by karl :
--
title: HTMLParser: parsing error -> HTMLParser: comma in attribute values
with/without space
___
Python tracker
<https://bugs.python.org/issu
karl added the comment:
Ah!
This is fixing it
diff --git a/Lib/html/parser.py b/Lib/html/parser.py
index 6083077981..790666 100644
--- a/Lib/html/parser.py
+++ b/Lib/html/parser.py
@@ -44,7 +44,7 @@
(?:\s*=+\s*# value indicator
Change by karl :
--
keywords: +patch
pull_requests: +22904
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/24072
___
Python tracker
<https://bugs.python.org/issu
Change by karl :
--
nosy: +karlcow
___
Python tracker
<https://bugs.python.org/issue28937>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from karl :
This comes up while working on issue 41748
browser input
data:text/html,text
browser output
text
Actual HTMLParser output
see https://github.com/python/cpython/pull/24072#discussion_r551158342
('starttag', 'div', [('class', 'b
karl added the comment:
The parsing rules for tokenization of html are at
https://html.spec.whatwg.org/multipage/parsing.html#tokenization
In the stack of open elements, there are specific rules for certain elements.
https://html.spec.whatwg.org/multipage/parsing.html#special
from a DOM
karl added the comment:
I wonder if the confusion comes from the name. The HTMLParser is kind of a
tokenizer more than a full HTML parser, but that's probably a detail. It
doesn't create a DOM Tree which you can access, but could help you to build a
DOM Tree (!= DOM Document obje
karl added the comment:
@zach.ware
@r.david.murray
I'm going through the source currently.
I see that the test file is using:
class MinidomTest(unittest.TestCase):
def confirm(self, test, testname = "Test"):
self.assertTrue(test, testname)
Is there a specifi
karl added the comment:
These methods are not used anywhere in the code.
https://github.com/python/cpython/blob/5c30145afb6053998e3518befff638d207047f00/Lib/xml/dom/minidom.py#L71-L80
What was the purpose when they were created… hmm maybe blame would give clue.
Ah they were added a long
karl added the comment:
Ah no. They ARE used
through defproperty and minicompat.py
get = getattr(klass, ("_get_" + name))
--
___
Python tracker
<https://bugs.python.o
Change by karl :
--
pull_requests: +22980
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24152
___
Python tracker
<https://bugs.python.org/issu
karl added the comment:
Status: The PR should be ready and completed
https://github.com/python/cpython/pull/24072
and eventually be merged at a point.
Thanks to ezio.melotti for the wonderful guidance.
--
___
Python tracker
<ht
karl added the comment:
This should be closed. The PR has been merged and the doc is now up to date.
--
nosy: +karlcow
___
Python tracker
<https://bugs.python.org/issue36
karl added the comment:
Same on macOS 10.15.6 (19G73)
Python 3.8.3 (v3.8.3:6f8c8320e9, May 13 2020, 16:29:34)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
karl added the comment:
Also this.
>>> import datetime
>>> d0 = datetime.datetime.strptime("2024-0-3 00:00:00", "%Y-%W-%w %H:%M:%S")
>>> d0.strftime("%Y-%W-%w %H:%M:%S")
'2024-01-3 00:00:00'
>>> d1 = datetime.dateti
New submission from karl :
In XPath 1.0
The function contains() is available
> Function: boolean contains(string, string)
> The contains function returns true if the first argument string contains the
> second argument string, and otherwise returns false.
In https://www.w3.org/TR
karl added the comment:
I'm at Mozilla All Hands this week.
I'll check if my solution still makes sense next week and will make a pull
request and/or propose another solution.
Thanks for the reminder. adding to my calendar.
--
___
Pyth
karl added the comment:
So I had time to look at it today.
And it would probably be better to solve
https://bugs.python.org/issue23312
which would make this one here useless and would actually provide a solution
for many people.
--
___
Python
karl added the comment:
This issue should probably be addressed now on
https://github.com/python/python-docs-theme
--
nosy: +karlcow
___
Python tracker
<https://bugs.python.org/issue23
karl added the comment:
I created https://github.com/python/python-docs-theme/issues/30
--
___
Python tracker
<https://bugs.python.org/issue23312>
___
___
Pytho
karl added the comment:
#8143 was fixed.
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import urlli
New submission from karl:
The current parsing of HTTP status line seems strange with regards to its
definition in HTTP.
http://hg.python.org/cpython/file/3.2/Lib/http/client.py#l307
Currently the code is
version, status, reason = line.split(None, 2)
>>> status1 = "H
karl added the comment:
ok.
status lines 1 and 2 are valid.
the third one is invalid and should trigger a
raise BadStatusLine(line)
The code at line 318 is bogus as it will parse happily the third line without
raising an exception.
http://hg.python.org/cpython/file/3.2/Lib/http/client.py
karl added the comment:
Fair enough, it could be a warning when
* more than one space in between http version and status code
* if there is a missing space after the status code
I'm not advocating for being strict only. I'm advocating for giving the tools
to developer to assess t
karl added the comment:
So what do we do with it?
Do I created a patch or do we close that bug? :)
No hard feelings about it.
--
___
Python tracker
<http://bugs.python.org/issue15
New submission from karl:
There is a room for a consistent and good EXIF library for the Python Standard
Library.
--
components: Library (Lib)
messages: 216978
nosy: karlcow
priority: normal
severity: normal
status: open
title: Missing Generic EXIF library for images in the standard
karl added the comment:
Mark,
The code is using urllib for demonstrating the issue with wikipedia and other
sites which are blocking python-urllib user agents because it is used by many
spam harvesters.
The proposal is about giving a possibility in robotparser lib to add a feature
for
karl added the comment:
Note that one of the proposal is to just document in
https://docs.python.org/3/library/urllib.robotparser.html
the proposal made in msg169722 (available in 3.4+)
robotparser.URLopener.version = 'MyVersion'
--
karl added the comment:
→ python
Python 2.7.5 (default, Mar 9 2014, 22:15:05)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import robot
karl added the comment:
Mark,
I'm happy to followup.
I will be in favor of removing any capitalization and not to change headers
whatever they are. Because it doesn't matter per spec. Browsers do not care
about the capitalization. And I haven't identified Web Compatibility is
karl added the comment:
@Mark,
yup, I can do that.
I just realized that since my contribution there was a PSF Contributor
Agreement. This is signed.
I need to dive a bit again in the code to remember where things fail.
--
___
Python tracker
<h
karl added the comment:
I had the issue today. I needed to parse a date with the following format.
2014-04-04T23:59:00+09:00
and could not with strptime.
I see a discussion in March 2014
http://code.activestate.com/lists/python-ideas/26883/ but no followup.
For references:
http
karl added the comment:
On closer inspection, Anders Hovmöller proposal doesn't work.
https://github.com/boxed/iso8601
At least for the microseconds part.
In http://tools.ietf.org/html/rfc3339#section-5.6, the microsecond part is
defined as:
time-secfrac= "." 1*DIGIT
I
karl added the comment:
Noticed some people doing the same thing
https://github.com/tonyg/python-rfc3339
http://home.blarg.net/~steveha/pyfeed.html
https://wiki.python.org/moin/WorkingWithTime
--
___
Python tracker
<http://bugs.python.
karl added the comment:
After inspections, the best library for parsing RFC3339 style date is
definitely:
https://github.com/tonyg/python-rfc3339/
Main code at
https://github.com/tonyg/python-rfc3339/blob/master/rfc3339.py
--
___
Python tracker
karl added the comment:
Ok this is an attempt at solving the issue with lowercase. I find my get_header
a bit complicated, but if you have a better idea. :) I'll modify the patches.
I have try to run the tests on the mac here but I have an issue currently.
→ ./python.exe -V
Python 3.
Changes by karl :
Removed file: http://bugs.python.org/file36695/issue-5550-3.patch
___
Python tracker
<http://bugs.python.org/issue5550>
___
___
Python-bugs-list mailin
karl added the comment:
And I had to do a typo in patch3. Submitting patch4. Sorry about that.
--
Added file: http://bugs.python.org/file36698/issue-5550-4.patch
___
Python tracker
<http://bugs.python.org/issue5
karl added the comment:
Just a follow up for giving the stable version of the now new RFC version for
HTTP 1.1
HTTP header field names parsing
http://tools.ietf.org/html/rfc7230#section-3.2.4
--
___
Python tracker
<http://bugs.python.
karl added the comment:
Ok my tests are ok.
→ ./python.exe -m unittest -v Lib/test/test_urllib2net.py
test_close (Lib.test.test_urllib2net.CloseSocketTest) ... ok
test_custom_headers (Lib.test.test_urllib2net.OtherNetworkTests) ... FAIL
test_file (Lib.test.test_urllib2net.OtherNetworkTests
New submission from karl:
→ ./python.exe -V
Python 3.4.2rc1+
→ hg tip
changeset: 92532:6dcc96fa3970
tag: tip
parent: 92530:ad45c2707006
parent: 92531:8eb4eec8626c
user:Benjamin Peterson
date:Mon Sep 22 22:44:21 2014 -0400
summary: merge 3.4 (#22459
karl added the comment:
Opened issue #22478 for the tests failing. Not related to my modification.
--
___
Python tracker
<http://bugs.python.org/issue5
karl added the comment:
ok let's see
→ ./python.exe -m unittest -v
Lib.test.test_urllib2net.OtherNetworkTests.test_custom_headers
test_custom_headers (Lib.test.test_urllib2net.OtherNetworkTests) ... FAIL
==
karl added the comment:
Ah! the User-Agent (or anything which is in unredirected_hdrs) will not be
updated if it has already been set once.
https://hg.python.org/cpython/file/064f6baeb6bd/Lib/urllib/request.py#l1154
>>> headers = dict(request.unredirected_hdrs)
>>> he
karl added the comment:
OK after fixing my repo (Thanks orsenthil) I got the tests running properly.
The inspection order of the two dictionary was not right, so I had to modify a
bit the patch.
→ ./python.exe -m unittest -v
Changes by karl :
Removed file: http://bugs.python.org/file36698/issue-5550-4.patch
___
Python tracker
<http://bugs.python.org/issue5550>
___
___
Python-bugs-list mailin
karl added the comment:
Let's close this.
>>> "HTTP/1.1301 ".split(None, 2)
['HTTP/1.1', '301']
>>> "HTTP/1.1301 ".split(' ', 2)
['HTTP/1.1', '', ' 301 ']
I think it would be
karl added the comment:
Where this is defined in the new RFC.
http://tools.ietf.org/html/rfc7230#section-3.1.2
status-line = HTTP-version SP status-code SP reason-phrase CRLF
Things to enforce
status-code= 3DIGIT
Response status code are now defined in
http://tools.ietf.org
karl added the comment:
This is the correct behavior
GET http://example.com/foo
with a response containing
302 and Location: /bar#test
must trigger
http://example.com/bar#test
Location is defined in
http://tools.ietf.org/html/rfc7231#section-7.1.2
7.1.2. Location
The "Loc
karl added the comment:
Takahashi-san,
Ah sorry misunderstood which part your were talking about. I assume wrongly you
were talking about navigation.
Yes for the request which is sent to the server it should be
http://tools.ietf.org/html/rfc7230#section-5.3.1
So refactoring your example
karl added the comment:
In class urlopen_HttpTests
https://hg.python.org/cpython/file/4f314dedb84f/Lib/test/test_urllib.py#l191
there is a test for invalid redirects
def test_invalid_redirect(self):
https://hg.python.org/cpython/file/4f314dedb84f/Lib/test/test_urllib.py#l247
And one for
karl added the comment:
OK I fixed the code. The issue is here
https://hg.python.org/cpython/file/1e1c6e306eb4/Lib/urllib/request.py#l656
newurl = urlunparse(urlparts)
Basically it reinjects the fragment in the new url. The fix is easy.
if urlparts.fragment
karl added the comment:
ooops right, my bad.
s/on port 8080. We first/on port 8080, we first/
better?
--
___
Python tracker
<http://bugs.python.org/issue11
karl added the comment:
Eric,
what do you recommend to move forward with this bug and patches?
Need guidance.
Do you have an example for "(A minor thing: I would use “attribute” instead of
“variable” in the docstrings.)"
Also which code base I should use? A lot of water has gone
karl added the comment:
On the mac version there is an issue with the python version installed
by default.
Python 2.5.1 (r251:54863, Jan 13 2009, 10:26:13)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
File
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/dbha
karl added the comment:
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-7.1.1
quoting from HTTP 1.1 bis
Prior to 1995, there were three different formats commonly used by
servers to communicate timestamps. For compatibility with old
implementations, all three
karl added the comment:
I think it is now fixed by my patch in http://bugs.python.org/issue747320
--
nosy: +karlcow
___
Python tracker
<http://bugs.python.org/issue7
karl added the comment:
Made a mistake in the previous server.patch, use server.2.patch
--
Added file: http://bugs.python.org/file29241/server2.patch
___
Python tracker
<http://bugs.python.org/issue747
Changes by karl :
Removed file: http://bugs.python.org/file29240/server.patch
___
Python tracker
<http://bugs.python.org/issue747320>
___
___
Python-bugs-list mailin
karl added the comment:
This is a possible additional example for set_tunnel, modification of
python3.3/html/_sources/library/http.client.txt
Hope it helps.
--
nosy: +karlcow
Added file: http://bugs.python.org/file29243/http.client.patch
___
Python
New submission from karl:
Are there plans to develop an HTTP/2.0 library in parallel of the specification
development? It will not be ready before years, but it would be good to have an
evolving implementation. Or should it be done outside of python.org?
Reference: https://github.com/http2
karl added the comment:
agreed on HTTP/1.1, is there a plan to fix it too ;) because the current
http.server seems to be untouchable without breaking stuff all around :)
--
___
Python tracker
<http://bugs.python.org/issue17
karl added the comment:
Testing your code in Listing 1
→ curl -sI http://localhost:9000/
HTTP/1.0 501 Unsupported method ('HEAD')
Server: BaseHTTP/0.6 Python/3.3.0
Date: Tue, 26 Feb 2013 23:38:32 GMT
Content-Type: text/html;charset=utf-8
Connection: close
So this is nor
karl added the comment:
OK I had understand a bit better.
self.send_error(code, msg) is used for
* The body
* The HTTP header
* and the log
That's bad, very bad.
I do not think it should be used for the HTTP Header at all.
--
___
Python tr
karl added the comment:
ok I modify the code of server.py so that the server doesn't send the private
message but the one which is already assigned by the library as it should. If
there is a need for customization, there should be two separate variables, but
which could lead to the
karl added the comment:
Read the thread. Thanks Antoine. Better understanding. I'm still discovering
how the community is really working.
Trying to fix a few things in the mean time
http://bugs.python.org/issue12921
http://bugs.python.org/issue747320
http://bugs.python.org/issue11448
New submission from karl:
def send_response_only(self, code, message=None):
http://hg.python.org/cpython/file/3.3/Lib/http/server.py#l448
There is no type checking on code or if the code is appropriate. Let's take
==
#!/usr/bin/env python3.3
i
karl added the comment:
Sentil:
About the PUT/POST, I would say:
A POST and PUT methods differs only by the
intent of the enclosed representation. In the
case of a POST, the target resource (URI) on
the server decides what is the meaning of the
enclosed representation
karl added the comment:
Note that HTTP header fields are case-insensitive.
See http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging#section-3.2
Each HTTP header field consists of a case-insensitive field name
followed by a colon (":"), optional whitespace, and the f
New submission from karl:
For HTTP header field names parsing, see
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-3.2.4
No whitespace is allowed between the header field-name and colon. In
the past, differences in the handling of such whitespace have led to
Changes by karl :
--
title: urllib.request add_header() currently allows trailing spaces ->
urllib.request add_header() currently allows trailing spaces (and other weird
stuff)
___
Python tracker
<http://bugs.python.org/issu
karl added the comment:
Yet another one leading spaces :(
>>> req = urllib.request.Request('http://www.example.com/')
>>> req.header_items()
[]
>>> req.add_header(' Foo3', 'Ooops')
>>> req.he
1 - 100 of 233 matches
Mail list logo
