[issue3244] multipart/form-data encoding

Martin Panter added the comment: I think encoding the user’s IP address into the boundary is a bad idea. Forest’s version uses the existing “email” package, which calls random.randrange(sys.maxsize) and searches through the data for conflicts. I haven’t really researched this, but I suspect it

[issue3244] multipart/form-data encoding

Changes by SilentGhost : -- Removed message: http://bugs.python.org/msg272583 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue3244] multipart/form-data encoding

Changes by SilentGhost : -- nosy: +Chris.Waigl, Johannes.Hoff, ajaksu2, alexz, atommixz, barry, bgamari, catalin.iacob, catlee, cco3, checat, daniel.ugra, eric.araujo, forest_atq, fsteinel, gotgenes, guettli, jnoller, martin.panter, orsenthil, piotr.dobrogost, pitrou, r.david.murray,

[issue3244] multipart/form-data encoding

lissacoffeyx added the comment: In principle I think something like this should go in. Since it is a Message subclass, I'd like it to follow the current Message API whether or not it is located in the email package. __str__ and as_string have the right default for line length (no folding).

[issue3244] multipart/form-data encoding

Changes by raylu : -- nosy: +raylu ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailm

[issue3244] multipart/form-data encoding

Changes by Martin Panter : -- nosy: +vadmium ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue3244] multipart/form-data encoding

Changes by Piotr Dobrogost : -- nosy: +piotr.dobrogost ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue3244] multipart/form-data encoding

Changes by Ezio Melotti : -- versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi Senthil Kumaran, Thanks for the feedback & patch. I agree having support in urllib probably makes some sense. But why not implement basic support elsewhere and then tie it into urllib so those of us using something else can also use it? I'm using httplib in

[issue3244] multipart/form-data encoding

Senthil Kumaran added the comment: Thanks for the patch, Forest Bond. However, the way I look at this feature, it could be added into urllib.request as a separate handler called MultiPostHandler and request object when it requires it should be able to add it and then use it. Here is a first

[issue3244] multipart/form-data encoding

R. David Murray added the comment: Thanks. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Okay, Contributor Agreement sent. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Sure thing. I'll send it via e-mail later today. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue3244] multipart/form-data encoding

R. David Murray added the comment: Forest, could you please submit a contributor agreement? http://www.python.org/psf/contrib/ Life caught up with me and I haven't made enough progress to do anything with this yet, but I still want to. -- assignee: r.david.murray -> components: +ema

[issue3244] multipart/form-data encoding

Changes by Ugra Dániel : -- nosy: +daniel.ugra ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue3244] multipart/form-data encoding

Changes by Aleksey Frolov : -- nosy: +atommixz ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue3244] multipart/form-data encoding

Changes by Conley Owens : -- nosy: +cco3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi, Johannes. You can assume the Python license for this patch. -Forest -- ___ Python tracker ___ ___

[issue3244] multipart/form-data encoding

Johannes Hoff added the comment: Forest Bond: Thanks for this patch - I hope it will go in soon. In the meantime, could I get permission to use it as is? (I notice there is a copyright in the file) I would of course keep the attributions in the file. -- nosy: +Johannes.Hoff _

[issue3244] multipart/form-data encoding

Changes by Catalin Iacob : -- nosy: +catalin.iacob ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue3244] multipart/form-data encoding

R. David Murray added the comment: In principle I think something like this should go in. Since it is a Message subclass, I'd like it to follow the current Message API whether or not it is located in the email package. __str__ and as_string have the right default for line length (no folding

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi, So is the following enough to get this applied? If so, I'm game. * Review RFC and enforce Content-Encoding: binary if applicable [checat]. * Generate CR+LF line endings [checat]. * Review RFC and address "line-splitting and header-folding" if applicable [ch

[issue3244] multipart/form-data encoding

Jesse Noller added the comment: Yeah, despite what the RFC says, the most common usage is in web clients, and stuffing it in the email module won't be obvious to 95% of the population I think, unless that's where the implementation lives, but we can add a doc stub in the http docs pointing to

[issue3244] multipart/form-data encoding

R. David Murray added the comment: This patch needs a Doc component. Having finally taken a quick look at the RFC (I haven't read it through yet), I think this does belong in email and not http. The RFC makes it clear that while the most common implementation is http, it is designed to be ge

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Looks like bgamari and I stepped on each other's requests. -- ___ Python tracker ___ ___ Python-bugs-li

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi, Sorry for the long delay. I have tested against a Python web application using restish via various WSGI web servers (CherryPy, wsgiref) and I have not seen problems. It may cause problems with other server-side implementations. I will not have time to do

[issue3244] multipart/form-data encoding

Ben Gamari added the comment: Has there been any progress here? -- nosy: +bgamari ___ Python tracker ___ ___ Python-bugs-list mailing

[issue3244] multipart/form-data encoding

Changes by R. David Murray : -- versions: +Python 3.3 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue3244] multipart/form-data encoding

Changes by Chris Waigl : -- nosy: +Chris.Waigl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue3244] multipart/form-data encoding

Konstantin Pelepelin added the comment: Did you test it against server-side form-data parser implementation? It will be useless if it won't work with most widespread implementations: PHP's and at least some others (consider some popular python web frameworks). MIME-compliance is not enough,

[issue3244] multipart/form-data encoding

Forest Bond added the comment: I don't think Python trunk has the encoders issue, as that is related to the base64 moving to the bytes type. -- ___ Python tracker ___ __

[issue3244] multipart/form-data encoding

Forest Bond added the comment: See issue8896 for email.encoders fix. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue3244] multipart/form-data encoding

Forest Bond added the comment: New patch: * Renames class to FormData. * Replaces method get_body with get_request_data to simplify semantics. * Drops changes to email.encoders. I'll create a new ticket to deal with that bug. Note that tests here fail without that fix. -- Added file

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hm, there is one issue. The example in the docstring wouldn't work. You have to get the headers *after* the body, because the boundary isn't generated until the body has been. So this would work: body = msg.get_body() headers = dict(msg) But this won't:

[issue3244] multipart/form-data encoding

Éric Araujo added the comment: Would you please open another issue for the email fix? Bonus points if you test it on trunk too, since release candidate happens in some days :) Do you people think we could unify client and server-side code in the new module (with an alias from cgi for b/w comp

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Here's a new patch. -- Added file: http://bugs.python.org/file17547/http_formdata.patch ___ Python tracker ___

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Éric, Sorry, I just read your message. I'll post a new patch with a module docstring. I believe cgi.FieldStorage is only useful for parsing (i.e. on the server side). MIMEMultipartFormData is for generating multipart/form-data messages (i.e. on the client sid

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi, Patch attached. Let me know what needs fixing. I had to fix a bug in email.encoders for my tests to pass. I have not run the full test suite at this point (need to build py3k to do that, maybe I'll have time later today, but if someone else has time, feel

[issue3244] multipart/form-data encoding

Éric Araujo added the comment: Seems good to me, as long as the module docstring clearly stats whether it’s useful for the client side, the server side or both. BTW, isn’t there overlap with cgi.FieldStorage? -- ___ Python tracker

[issue3244] multipart/form-data encoding

Forest Bond added the comment: As http.formdata? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue3244] multipart/form-data encoding

Éric Araujo added the comment: I think it belongs in the http package. -- nosy: +merwok ___ Python tracker ___ ___ Python-bugs-list ma

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Should the module be called rfc2388 or should it go into email.mime as formdata? It seems odd to put something HTML/HTTP related into email.mime, but maybe that would be fine. In any case, httplib docs should probably point to this module with an example, righ

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Okay, I'll submit against py3k. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue3244] multipart/form-data encoding

Antoine Pitrou added the comment: > I haven't yet touched Python 3.0, and may not have time to dig in at > the moment. It wouldn't be suitable to provide a patch against 2.7? 2.7 is almost in release candidate phase, which means it's much too late for new features now. -- ___

[issue3244] multipart/form-data encoding

Forest Bond added the comment: I haven't yet touched Python 3.0, and may not have time to dig in at the moment. It wouldn't be suitable to provide a patch against 2.7? -- ___ Python tracker __

[issue3244] multipart/form-data encoding

Antoine Pitrou added the comment: You should write your patch against Python 3.x (py3k). -- nosy: +pitrou ___ Python tracker ___ ___ P

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Oh, hm, looks like I left a hard-coded name="files" in attach_file. I'll fix that in the patch after I've received any other feedback. -- ___ Python tracker

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi, I believe the attached implementation is reasonable. I'm not sure if it should be called "email.mime.formdata", "rfc2388", etc. I'd be happy to attach a proper patch with tests given some quick feedback. Thanks, Forest -- nosy: +forest_atq Added f

[issue3244] multipart/form-data encoding

Changes by R. David Murray : -- assignee: -> r.david.murray versions: +Python 3.2 -Python 2.7 ___ Python tracker ___ ___ Python-bugs-l

[issue3244] multipart/form-data encoding

Changes by Barry A. Warsaw : -- assignee: barry -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue3244] multipart/form-data encoding

R. David Murray added the comment: Daniel suggested marking this as superseding issue 727898, and I agree. But I want to note that in that issue Barry suggested that it was possible services from the email package could be useful in building this support, and that there might be a better pla

[issue3244] multipart/form-data encoding

Changes by Thomas Guettler : -- nosy: +guettli ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue3244] multipart/form-data encoding

Jesse Noller added the comment: This request really does need a patch+tests+doc changes - I don't know if anyone with +commit has the time to distill the various implementations and generate something. -- nosy: +jnoller ___ Python tracker

[issue3244] multipart/form-data encoding

Andrey Petrov added the comment: Once upon a time I wrote a library that did some of this among other things: http://code.google.com/p/urllib3/ Or specifically: http://code.google.com/p/urllib3/source/browse/trunk/urllib3/filepost.py The code was borrowed from some of the recipes mentioned, b

[issue3244] multipart/form-data encoding

Changes by Bertrand Janin : -- nosy: +tamentis ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue3244] multipart/form-data encoding

Changes by Alex Z. : -- nosy: +alexz ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mail

[issue3244] multipart/form-data encoding

Changes by Barry A. Warsaw : -- assignee: -> barry nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue3244] multipart/form-data encoding

Changes by Daniel Diniz : -- priority: -> normal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue3244] multipart/form-data encoding

Changes by Daniel Diniz : -- dependencies: +Support iterable bodies in httplib keywords: +easy nosy: +orsenthil stage: -> test needed ___ Python tracker ___ _

[issue3244] multipart/form-data encoding

Daniel Diniz added the comment: So, what is the best way to go about this (beyond docs and tests)? Beat the linked recipe into a patch, adapt Chris' implementation? -- nosy: +ajaksu2 ___ Python tracker

[issue3244] multipart/form-data encoding

Changes by Chris Lasher : -- nosy: +gotgenes ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue3244] multipart/form-data encoding

Chris AtLee <[EMAIL PROTECTED]> added the comment: I also wrote some software to handle this: http://atlee.ca/software/poster/poster.encode.html The reason I wrote this is to avoid having the load the entire file into memory before posting the request. This, along with Issue #3243, would allow

[issue3244] multipart/form-data encoding

Florian Steinel <[EMAIL PROTECTED]> added the comment: see http://code.activestate.com/recipes/146306/ for a user contributed implementation. -- nosy: +fsteinel ___ Python tracker <[EMAIL PROTECTED]>

[issue3244] multipart/form-data encoding

New submission from Chris AtLee <[EMAIL PROTECTED]>: The standard library should provide a way to encode data using the standard multipart/form-data encoding. This encoding is required to support file uploads via HTTP POST (or PUT) requests. Ideally file data could be streamed to the remote ser