[issue3609] does parse_header really belong in CGI module?

Change by Senthil Kumaran : -- stage: needs patch -> resolved status: languishing -> closed ___ Python tracker ___ ___ Python-bugs-li

[issue3609] does parse_header really belong in CGI module?

Senthil Kumaran added the comment: Closing this age old bug in favor of fixing it as part of issue23498. -- resolution: -> wont fix ___ Python tracker ___

[issue3609] does parse_header really belong in CGI module?

Martin Panter added the comment: I opened Issue 23498 about exposing split_header_words() or similar. So this issue can focus on moving parse_header() to an email.policy.HTTP method or whatever. RTSP 1.0 and its Transport header is defined in RFC 2326:

[issue3609] does parse_header really belong in CGI module?

Changes by Berker Peksag : -- nosy: +berker.peksag ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue3609] does parse_header really belong in CGI module?

R. David Murray added the comment: We can also add a parser for that format to headerregistry. Is there an RFC that describes it? (It should probably be a separate issue.) The new email API will be promoted to stable in 3.5. Mostly I just need to update the docs. -- __

[issue3609] does parse_header really belong in CGI module?

Martin Panter added the comment: HTTP policy sounds as good a place as any, especially if/when it is blessed as a stable API. Another related function is the undocumented http.cookiejar.split_header_words(), which seems more flexible than cgi.parse_headers(). It accepts multiple and comma-sep

[issue3609] does parse_header really belong in CGI module?

R. David Murray added the comment: There is no reason to move this to the email package. email can already parse headers just fine. It might be useful to have a parse_header utility method, though, since currently the easiest way to parse a single header using the email package is: >>> fr

[issue3609] does parse_header really belong in CGI module?

Martin Panter added the comment: Good idea to move this to somewhere more visible and obvious. I would have been using parse_header() much earlier if I had known it existed. However, maybe it would be better off in the “email.message” module. The rest of the “email.header” module only seems to

[issue3609] does parse_header really belong in CGI module?

Florent Xicluna added the comment: This refactoring between cgi and email modules is languishing for few years. Any thought? -- status: open -> languishing versions: +Python 3.4 -Python 3.2 ___ Python tracker _

[issue3609] does parse_header really belong in CGI module?

Changes by Florent Xicluna : -- nosy: +flox stage: -> patch review versions: +Python 3.2 -Python 3.0 ___ Python tracker ___ ___ Python

[issue3609] does parse_header really belong in CGI module?

Senthil added the comment: The attached patch takes care of relocating the parse_header function from cgi module to email.header module in Python2.7. Few comments: 1)parse_multipart need not be moved from cgi, because it is discouraged to use parse_multipart and it is advised to use FieldStora

[issue3609] does parse_header really belong in CGI module?

Changes by Senthil <[EMAIL PROTECTED]>: -- nosy: +orsenthil ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing list

[issue3609] does parse_header really belong in CGI module?

Bill Janssen <[EMAIL PROTECTED]> added the comment: > I imagine if they were moved (at least for a few versions) the old ones > would still work, with a deprecation warning? Yes, that's what I was thinking. ___ Python tracker <[EMAIL PROTECTED]>

[issue3609] does parse_header really belong in CGI module?

Matt Giuca <[EMAIL PROTECTED]> added the comment: These functions are for generic MIME headers and bodies, so are applicable to CGI, HTTP, Email, and any other protocols based on MIME. So I think having them in email.header makes about as much sense as having them in cgi. Isn't mimetools a bette

[issue3609] does parse_header really belong in CGI module?

New submission from Bill Janssen <[EMAIL PROTECTED]>: Not sure how to class this, but shouldn't the "parse_header" function in cgi really be in email.header? And what about parse_multipart? -- components: Library (Lib) messages: 71500 nosy: janssen priority: normal severity: normal stat