[issue401121] cosmetic cleanup of cgi.py, using Guido's style conventions

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue515006] remove unused import in lib/cgi.py

Change by admin : -- github: None -> 36058 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue443120] denial-of-service attack to cgi.py

Change by admin : -- github: None -> 34799 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue411612] cgi.py sometimes ignores QUERY_STRING

Change by admin : -- github: None -> 34239 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue232124] [PATCH] simple fix, cgi.py uses /usr/local/bin/python ?

Change by admin : -- github: None -> 33915 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue231249] cgi.py opens too many (temporary) files

Change by admin : -- github: None -> 33858 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue219806] cgi.py uses too much memory on large file uploads

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue219806] cgi.py uses too much memory on large file uploads

Change by admin : -- github: None -> 33418 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401121] cosmetic cleanup of cgi.py, using Guido's style conventions

Change by admin : -- github: None -> 32901 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28375] cgi.py spam in Apache server logs

Irit Katriel added the comment: Thanks Sebastian, I'll close this and if someone still sees this problem they will report it. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue28375] cgi.py spam in Apache server logs

Sebastian Rittau added the comment: All my projects now use werkzeug instead of the cgi module, so I can't confirm whether this problem still exists. I'm fine with closing this as unreproducible if no one else can reproduce it. -- status: pending -> open

[issue28375] cgi.py spam in Apache server logs

Change by Irit Katriel : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28375] cgi.py spam in Apache server logs

Irit Katriel added the comment: There's been quite a few changes in finalization (thanks to Victor) since 3.5/3.6. Are you seeing this problem on 3.9+? Can you provide instructions how to reproduce it? -- nosy: +iritkatriel, vstinner ___

[issue21705] cgi.py: Multipart with more than one file is misparsed

Change by Rhodri James : -- nosy: -Rhodri James ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21705] cgi.py: Multipart with more than one file is misparsed

Ethan Furman added the comment: Excellent, thanks for checking! -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue21705] cgi.py: Multipart with more than one file is misparsed

Pierre Quentel added the comment: @ethan.furman Yes, in test_cgi.py, the method test_fieldstorage_multipart_w3c https://github.com/python/cpython/blob/master/Lib/test/test_cgi.py#L316) uses a multipart content with 2 files in it

[issue21705] cgi.py: Multipart with more than one file is misparsed

Ethan Furman added the comment: The last status was "test-needed" -- has anyone verified that a test exists for this scenario? -- ___ Python tracker ___

[issue21705] cgi.py: Multipart with more than one file is misparsed

Change by Dong-hee Na : -- resolution: -> fixed stage: test needed -> resolved status: open -> closed ___ Python tracker ___ ___

[issue21705] cgi.py: Multipart with more than one file is misparsed

Pierre Quentel added the comment: The patch has been applied some time ago (I couldn't find the exact commit), cf. https://github.com/python/cpython/blob/master/Lib/cgi.py#L750 I think we can close the issue. -- nosy: +quentel ___ Python tracker

[issue21705] cgi.py: Multipart with more than one file is misparsed

Change by Rhodri James : -- nosy: +Rhodri James, ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1610654] cgi.py multipart/form-data

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28375] cgi.py spam in Apache server logs

yoch added the comment: Same issue here (python 3.6). This is very annoying, especially in case of large entries in FieldStorage, because the whole data is written to the log. Example: FieldStorage('image', 'upload.jpg', b'...can be very long...') -- components: +Library (Lib)

[issue11066] cgi.py proposals : sys.stdout encoding + rewriting of parsing functions

Pierre Quentel added the comment: I close this issue and will open a more specific one for the rewriting of parse_multipart() -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue28375] cgi.py spam in Apache server logs

New submission from Sebastian Rittau: I am using cgi.py in WSGI applications, using Apache and mod_wsgi. Unfortunately cgi.py keeps spamming the error log with messages like the following: Exception ignored in: Traceback (most recent call last): File "/usr/lib/python3.5/cgi.py"

[issue1610654] cgi.py multipart/form-data

Rishi added the comment: There is indeed a test failure that occurs without the patch. This is a new test I had added. The reason is that in the existing implementation, when a boundary does not exist, the implementation does not include the trailing CRLF, LF or for that matter CR as part of

[issue1610654] cgi.py multipart/form-data

Rishi added the comment: One of my comments shot the wrapped line limit. Also changed the test in question to check the lengths of the expected and actual buffer to checking the contents of the respective buffers. -- Added file: http://bugs.python.org/file37400/issue1610654_5.patch

[issue1610654] cgi.py multipart/form-data

Serhiy Storchaka added the comment: New test fail with non-modified code. Either there is a bug in current code or tests are wrong. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654

[issue1610654] cgi.py multipart/form-data

Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654 ___ ___

[issue1610654] cgi.py multipart/form-data

Rishi added the comment: Hi, I have created a new patch with a small design change. The change is that in situations where I don't find the boundary instead of keeping the last x bytes in the buffer I simply drain the whole data and call a readline(). This seems like the right thing to do

[issue1610654] cgi.py multipart/form-data

Rishi added the comment: Patch updated from review comments. Also added a few corner test cases. -- Added file: http://bugs.python.org/file37128/issue1610654_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654

[issue1610654] cgi.py multipart/form-data

Antoine Pitrou added the comment: Thanks for the updated patch. I'll take a look soon if no-one beats me to it. -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654

[issue1610654] cgi.py multipart/form-data

Serhiy Storchaka added the comment: I doubt we can use io.BufferedReader or handmade buffering here. Current code doesn't read more bytes than necessary. Buffered reader will read ahead, and there is no way to return read bytes back to the stream in general case (an exception is seekable

[issue1610654] cgi.py multipart/form-data

Rishi added the comment: I have recreated the patch(issue1610654_1.patch) and it performs more or less like the earlier patch Serhiy, I agree we cannot use handmade buffering here, without seeking ahead. I believe, we can make optimizations for streams which are buffered and non-seekable. Cgi

[issue1610654] cgi.py multipart/form-data

Rishi added the comment: My observation is that a file with more than normal (exact numbers below) line-feed characters takes way too long. I tried porting the above patch to my default branch, but it has some boundary and CRLF/LF issues, but more importantly it relies on seeking the

[issue1610654] cgi.py multipart/form-data

Antoine Pitrou added the comment: Rishi, thanks for the patch. I was going to give a review but first I have to ask: is so much support code necessary for this? Another approach would be to wrap self.fp in a io.BufferedReader (if it's not already buffered) and then use the peek() method to

[issue1610654] cgi.py multipart/form-data

Rishi added the comment: Antoine, I will upload a patch that relies on BufferedReader. As you mentioned, it will get rid of supporting the buffer and reduce a lot of code. The only issue is that it helps me to know if the current buffer is at EOF (the documentation of peek does not mention

[issue1610654] cgi.py multipart/form-data

R. David Murray added the comment: To move this issue along we need someone to convert it into our standard patch format (a unified diff against either the 3.4 or the default branch, preferrably produced via an 'hg diff' command without the --git option), with the test included as a unit test

[issue1610654] cgi.py multipart/form-data

Hynek Schlawack added the comment: I would have long ago if I had any domain knowlege on this topic, but alas…. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654 ___

[issue1610654] cgi.py multipart/form-data

Chui Tey added the comment: Hi, I'm still available. There's a test case in the patch, would you like me to separate that to another file? Would that help with assessing it? Best, On 8 July 2014 22:05, Hynek Schlawack rep...@bugs.python.org wrote: Hynek Schlawack added the comment: I

[issue1610654] cgi.py multipart/form-data

Mark Lawrence added the comment: @Hynek could you port the patch as you've shown some interest in it? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654 ___

[issue21705] cgi.py: Multipart with more than one file is misparsed

New submission from Matthias Urlichs: This code in cgi.py makes no sense whatsoever: 842 if line.endswith(b--) and last_line_lfend: 843 strippedline = line.strip() 844 if strippedline == next_boundary: 845 break 846

[issue21705] cgi.py: Multipart with more than one file is misparsed

Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21705 ___

[issue1610654] cgi.py multipart/form-data

Hynek Schlawack added the comment: It would be great if someone could port this patch to Python 3.4 and verify its effectiveness. -- keywords: +easy -patch stage: test needed - needs patch versions: +Python 3.4 -Python 3.2, Python 3.3 ___ Python

[issue1610654] cgi.py multipart/form-data

Changes by Atsuo Ishimoto ishim...@gembook.org: -- nosy: +ishimoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654 ___ ___ Python-bugs-list

[issue1610654] cgi.py multipart/form-data

Florent Xicluna florent.xicl...@gmail.com added the comment: It needs tests to demonstrate the issue in 3.x, and an updated patch. -- nosy: +hynek, pitrou stage: patch review - test needed versions: +Python 3.3 ___ Python tracker

[issue1610654] cgi.py multipart/form-data

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654 ___ ___ Python-bugs-list

[issue11066] cgi.py proposals : sys.stdout encoding + rewriting of parsing functions

Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11066 ___ ___

[issue11066] cgi.py proposals : sys.stdout encoding + rewriting of parsing functions

Éric Araujo mer...@netwok.org added the comment: See also #1610654 and #6234. -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11066 ___

[issue10480] cgi.py should document the need for binary stdin/stdout

Glenn Linderman v+pyt...@g.nevcal.com added the comment: Fixed by issue 10841 and issue 4953. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10480 ___

[issue11066] cgi.py proposals : sys.stdout encoding + rewriting of parsing functions

New submission from Pierre Quentel pierre.quen...@gmail.com: Python 3.2rc1 introduced a new version of cgi.py that handles correctly file uploads In this version, the FieldStorage constructor receives an argument encoding which is the encoding used by the document holding the submitted form

[issue8846] cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken

Andre Wobst wob...@users.sourceforge.net added the comment: I just declare this bug to be a duplicate of #4953. Due to the recent fix r87998 of the cgi module my extended/corrected testcases attached in this bug report now pass. -- resolution: - duplicate status: open - closed

[issue6886] cgi.py runs python, not python3

Changes by Éric Araujo mer...@netwok.org: -- resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - make altinstall installs many files with incorrect shebangs ___ Python tracker rep...@bugs.python.org

[issue10480] cgi.py should document the need for binary stdin/stdout

severity: normal status: open title: cgi.py should document the need for binary stdin/stdout versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10480

[issue10480] cgi.py should document the need for binary stdin/stdout

Changes by Glenn Linderman v+pyt...@g.nevcal.com: -- assignee: - d...@python components: +Documentation nosy: +d...@python type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10480

[issue1610654] cgi.py multipart/form-data

R. David Murray rdmur...@bitdance.com added the comment: I don't think it was appropriate to close this issue. -- nosy: +r.david.murray -BreamoreBoy resolution: wont fix - stage: unit test needed - patch review status: closed - open versions: +Python 3.2 -Python 2.7, Python 3.1

[issue1610654] cgi.py multipart/form-data

Changes by Florent Xicluna florent.xicl...@gmail.com: -- nosy: +flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654 ___ ___

[issue8846] cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken

Changes by Florent Xicluna florent.xicl...@gmail.com: -- nosy: +flox versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8846 ___

[issue1610654] cgi.py multipart/form-data

Mark Lawrence breamore...@yahoo.co.uk added the comment: No reply to msg110090. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654 ___

[issue1540529] cgi.py error on parsing/handling content-disposition

Terry J. Reedy tjre...@udel.edu added the comment: With 3.1.2, cgi.parse_header gives the same correct response as cgtest.parse_header, so I will assume that the same is true in 2.7 until demonstrated otherwise. -- nosy: +tjreedy resolution: - fixed status: open - closed

[issue1610654] cgi.py multipart/form-data

Mark Lawrence breamore...@yahoo.co.uk added the comment: Chui Tey does this issue still apply? If yes, could you please provide a patch according to the guidelines here. python.org/dev/patches -- nosy: +BreamoreBoy ___ Python tracker

[issue8846] cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken

, the bugs are fixed by two small corrections to cgi.py and email/feedparser.py. Thanks for consideration. -- components: Library (Lib) files: fix-cgi.patch keywords: patch messages: 106691 nosy: wobsta priority: normal severity: normal status: open title: cgi.py bug report + fix: tailing

[issue8846] cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken

Changes by Andre Wobst wob...@users.sourceforge.net: -- type: - behavior versions: +Python 3.1 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8846 ___

[issue6886] cgi.py runs python, not python3

Jack Diederich jackd...@gmail.com added the comment: +0 I'm ambivalent. The script uses a reasonable default and pyhton3 is a reasonable default for the 3k branch. That said most people will have to edit the file anyway to use it: I had to chmod a+x the file and change the bang path to

[issue6886] cgi.py runs python, not python3

New submission from Mitchell Model m...@acm.org: The file cgi.py in the lib directory is an executable beginning with the line: #! /usr/local/bin/python Shouldn't that be python3? -- components: Library (Lib) messages: 92517 nosy: MLModel severity: normal status: open title: cgi.py

[issue1159139] cgi.py invalid REQUEST_METHOD set

Georg Brandl ge...@python.org added the comment: Turns out this is caused by setting REQUEST_METHOD to 'cgi', which is completely unmotivated. Not doing this lets the example script work fine. -- nosy: +georg.brandl resolution: - works for me status: open - closed

[issue1610654] cgi.py multipart/form-data

Changes by Daniel Diniz aja...@gmail.com: -- components: +Library (Lib) -Interpreter Core keywords: +patch stage: - test needed type: - performance versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org

[issue1055234] cgi.py does not correctly handle fields with ';'

Fred L. Drake, Jr. [EMAIL PROTECTED] added the comment: This is now fixed for Python 2.6.?, 2.7, 3.0.1, and 3.1. I've no idea why I didn't write a test for this sooner. -- resolution: - fixed stage: - committed/rejected status: open - closed ___

[issue1540529] cgi.py error on parsing/handling content-disposition

Oleksiy Golovko [EMAIL PROTECTED] added the comment: Here is the another patch for this issue. -- nosy: +zindel title: cgi.py error on parsing/handling content-disposition - cgi.py error on parsing/handling content-disposition Added file: http://bugs.python.org/file10996/cgtest.py

Re: Un(der)documented bits of cgi.py

). If the file is large enough, and the user is impatient enough, this can result in the FieldStorage.file object getting some, but not all of the bytes from the user's file, with no documented means of detecting that this has happened. Poking around in the code for cgi.py in the standard library

Re: Un(der)documented bits of cgi.py

Aahz wrote: What I suggest doing is submitting a doc patch to http://bugs.python.org/ Done. Thanks for the suggestion. Bob -- http://mail.python.org/mailman/listinfo/python-list

Un(der)documented bits of cgi.py

, this can result in the FieldStorage.file object getting some, but not all of the bytes from the user's file, with no documented means of detecting that this has happened. Poking around in the code for cgi.py in the standard library, it appears that there is an undocumented 'done' attribute which

cgi.py bug submitted to source_forge - Martin v. L�wis

I submitted a patch quite a while back for a bug in cgi.py (see source forge 1159139) Martin, I posted this here, hoping you would see the message. Back in March 2007 you were looking at this bug and updated the item on source forge looking for more details. I have documented the bug further

multiple content-types break cgi.py

Hi! The Nokia Java SDK allows one to define multiple content-types in a single HTTP header field. I'm not sure if it's standard, but it's happening from some Java-enabled phones. This breaks the FieldStorage class in cgi.py by not causing self.read_urlencoded() to be called at object init

Re: multiple content-types break cgi.py

In article [EMAIL PROTECTED], Janto Dreijer wrote: The Nokia Java SDK allows one to define multiple content-types in a single HTTP header field. I'm not sure if it's standard, but it's happening from some Java-enabled phones. The only reference to this bug I can find dates back to 1999:

Re: multiple content-types break cgi.py

In [EMAIL PROTECTED], Jon Ribbens wrote: It's not a bug - sending multiple content-types is just totally broken. What would such a header even be supposed to mean? It's like saying this is an apple orange. And the correct header for such a beast would be this is an iOrange of course. ;-)

Re: multiple content-types break cgi.py

inspection suggests that calling connection.setRequestProperty(Content-Type, application/x-www- form-urlencoded); on the Nokia 6230 would actually cause the value to be *appended* and not set. Yuck! It looks like I'm going to have to keep a modified copy of cgi.py if I want to support the phone

Re: multiple content-types break cgi.py

In article [EMAIL PROTECTED], Janto Dreijer wrote: It's not a bug - sending multiple content-types is just totally broken. What would such a header even be supposed to mean? It's like saying this is an apple orange. Hmmm. Thanks! I suspected as much. Rough inspection suggests that calling

[ python-Bugs-1610654 ] cgi.py multipart/form-data

of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chui Tey (teyc) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py multipart/form-data

Optimization of __len__() in cgi.py

I have a suggestion for speeding up the performance of code like this: fields = cgi.FieldStorage() if fields: ... which, as it turns out, invokes FieldStorage.__len__(), which in turn calls FieldStorage.keys(), which builds a list of keys by hand, taking several minutes for large forms. This

Re: Optimization of __len__() in cgi.py

In [EMAIL PROTECTED], Bob Kline wrote: I have a suggestion for speeding up the performance of code like this: fields = cgi.FieldStorage() if fields: ... which, as it turns out, invokes FieldStorage.__len__(), which in turn calls FieldStorage.keys(), which builds a list of keys by hand,

Re: Optimization of __len__() in cgi.py

Bob Kline wrote: I have a suggestion for speeding up the performance of code like this: fields = cgi.FieldStorage() if fields: ... which, as it turns out, invokes FieldStorage.__len__(), which in turn calls FieldStorage.keys(), which builds a list of keys by hand, taking several minutes

Re: Optimization of __len__() in cgi.py

Marc 'BlackJack' Rintsch wrote: def keys(self): return {}.fromkeys([i.name for i in self.list]).keys() This does not maintain the order of `self.list`. Don't know if there's code relying on this. Such code would be flying in the face of an implication that the order of the keys

Re: Optimization of __len__() in cgi.py

Sybren Stuvel wrote: FieldStorage.__nonzero__ tried first if it exists. You might want to use that for more optimization. Excellent suggestion! It would be nice if this were adopted to supplement the original optimization, rather than replace it. Bob --

Re: Optimization of __len__() in cgi.py

Georg Brandl wrote: Post a RFE to the Python Tracker at http://sourceforge.net/tracker/?group_id=5470atid=355470 If you want, assign it to me (gbrandl). Done, thanks. Bob -- http://mail.python.org/mailman/listinfo/python-list

[ python-Bugs-1540529 ] cgi.py error on parsing/handling content-disposition

of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Dirk Holtwick (holtwick) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py error on parsing

Bug Report / Patch (1159139 cgi.py invalid REQUEST_METHOD set)

Back in March I submitted a patch for cgi.py to sourceforge to fix a problem with the handling of an invalid REQUEST_METHOD. I thought I followed all the steps to properly submit the bug and patch but the patch is still sitting there in limbo. This is the first patch I have submitted

Re: Bug Report / Patch (1159139 cgi.py invalid REQUEST_METHOD set)

Joe wrote: Back in March I submitted a patch for cgi.py to sourceforge to fix a problem with the handling of an invalid REQUEST_METHOD. I thought I followed all the steps to properly submit the bug and patch but the patch is still sitting there in limbo. This is the first patch I have

Re: Bug Report / Patch (1159139 cgi.py invalid REQUEST_METHOD set)

Joe wrote: Back in March I submitted a patch for cgi.py to sourceforge to fix a problem with the handling of an invalid REQUEST_METHOD. I thought I followed all the steps to properly submit the bug and patch but the patch is still sitting there in limbo. Patches get processed when people

Re: Bug Report / Patch (1159139 cgi.py invalid REQUEST_METHOD set)

field = cgi.FieldStorage() print field print field.keys()# NEW Run the program now with NO parameters. (I'm running on WinXP SP2). After you start the program cgi.py will be reading from stdin. type a=1 and hit enter type b=2 and hit enter press ctrl-z (to send eof) and hit enter You will get

cgi.py?

Hi, I've looked into cgi.py from 2.4's distribution, and its contents puzzle me. In parse_header, the first line splits on ';': plist = map(lambda x: x.strip(), line.split(';')) but header parameters may contain semicolon in quoted strings: Content-Type: image/jpeg; filename=home:lib

Re: cgi.py?

david I've looked into cgi.py from 2.4's distribution, and its contents david puzzle me. In parse_header, the first line splits on ';': david plist = map(lambda x: x.strip(), line.split(';')) david but header parameters may contain semicolon in quoted strings: david

cgi.py bug

While debugging a problem I was having I found a bug in the cgi.py module. When the environment does not have a correctly set REQUEST_METHOD cgi.py prompts for key=value pairs by reading from sys.stdin. After the values are read from sys.stdin they are never stored in the FieldStorage.list

Re: Newbie: A very basic problem related to cgi.py

Steve Holden wrote: Traceback (most recent call last): File cgi.py, line 2, in ? import cgi File /c/steve/cgi.py, line 12, in ? main() File /c/steve/cgi.py, line 6, in main form = cgi.FieldStorage() AttributeError: 'module' object has no attribute 'FieldStorage' Ha! There's

Re: Newbie: A very basic problem related to cgi.py

You are right, I had first named my file cgi.py... but then i realized that it was causing conflicts so i renamed it to mycgi.py as you can see in the trace, but the problem persisted... After reading your reply i took a look at the directory i was in and there was a pyc file in it... cgi.pyc, i

Re: Newbie: A very basic problem related to cgi.py

Steve Holden wrote: Peter Hansen wrote: I suspected that too, Steve, but why would it be showing the library cgi.py in the traceback if he had a local one with the same name? Weird. (Unless, as I wondered in my redundant reply, the traceback he posted wasn't the real traceback