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 in the POST request.
In a PUT request, the enclosed representation
is meant to replace the state of the target
resource (URI) on the server.
It is why PUT is idempotent.
About the code:
* http.client
I would remove the following comment, because the term "file" is confusing in
HTTP terms.
# This will create a resource file with contents of BODY
or I would say more exactly
# This creates an HTTP message
# with the content of BODY as the enclosed representation
# for the resource http://localhost:8080/foobar
>>> import http.client
>>> BODY = "Some data"
>>> conn = http.client.HTTPConnection("localhost", 8080)
>>> conn.request("PUT", "/foobar", BODY) # The actual PUT Request
>>> response = conn.getresponse()
>>> print(resp.status, response.reason)
Maybe it would be good to display the message which is sent so people can
understand what goes on the wire.
* urllib
the client code for urllib doesn't create challenge, I would had a content-type
but no hard feeling about it. On the other hand the server code makes me a bit
uncomfortable. It sets people into believing that this is the way you should
reply to a PUT which is not really the case.
1. If the resource was not existing and has been successfully created, the
server MUST answer 204.
2. if the resource already exists and has been successfully replaced/modified,
then the server SHOULD answer either 200 or 204 (depending on the design choice)
There are plenty of other cases depending on the constraints. See for the
details
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-4.3.4
If we keep the server code, I would be willing to have a note saying that it is
not usable as-is in production code.
Does that make sense? :)
----------
nosy: +karlcow
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17307>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
