[issue3609] does parse_header really belong in CGI module?

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

[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?

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?

Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3609 ___ ___

[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: from

[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

[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

[issue3609] does parse_header really belong in CGI module?

Florent Xicluna florent.xicl...@gmail.com 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 florent.xicl...@gmail.com: -- nosy: +flox stage: - patch review versions: +Python 3.2 -Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3609 ___

[issue3609] does parse_header really belong in CGI module?

Senthil orsent...@gmail.com 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

[issue3609] does parse_header really belong in CGI module?

Changes by Senthil [EMAIL PROTECTED]: -- nosy: +orsenthil ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3609 ___ ___ 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?

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 status:

[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 better