CGIHTTPServer support for arbitrary CGI scripts

[9432cd65-9f88-4bc6-8ad6-72e5ab1c730d]

BPO	9008
Nosy	@orsenthil, @pitrou, @merwok, @vadmium

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['type-feature', 'library'] title = 'CGIHTTPServer support for arbitrary CGI scripts' updated_at = user = 'https://bugs.python.org/techtonik' ``` bugs.python.org fields: ```python activity = actor = 'BreamoreBoy' assignee = 'none' closed = False closed_date = None closer = None components = ['Library (Lib)'] creation = creator = 'techtonik' dependencies = [] files = [] hgrepos = [] issue_num = 9008 keywords = [] message_count = 13.0 messages = ['107912', '107916', '107917', '107919', '107920', '107921', '107922', '108006', '108009', '108012', '108013', '108216', '220670'] nosy_count = 5.0 nosy_names = ['orsenthil', 'pitrou', 'techtonik', 'eric.araujo', 'martin.panter'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue9008' versions = ['Python 3.5'] ```

[9432cd65-9f88-4bc6-8ad6-72e5ab1c730d]

CGIHTTPServer should support all CGI scripts, not only Python ones.

[merwok]

I suspect this bug will sit here languishing without action, for various reasons:

1) From other doc discussion, I assume you won’t be able to propose a patch.

2) There is no dedicated maintainer for http or cgi.

3) CGI is a low-level, archaic, inefficient interface.

4) The cgi server has grave bugs like this one (from the doc): “CGI scripts run by the CGIHTTPRequestHandler class cannot execute redirects (HTTP code 302), because code 200 (script output follows) is sent prior to execution of the CGI script.”

[merwok]

Forgot the conclusion: I suspect noone will want to work on that.

(I removed 2.7 since it’s feature frozen.)

[orsenthil]

On Wed, Jun 16, 2010 at 12:16:38PM +0000, Éric Araujo wrote:

Forgot the conclusion: I suspect noone will want to work on that.

Nope, please don't come to that conclusion soon. It is a valid request. It is not that only maintainers listed will work on those.

(I removed 2.7 since it’s feature frozen.)

This is fine.

[merwok]

Sorry, somehow I forgot the ton of work you’ve been putting into urlparse and urllib :)

Note that I never said or thought it was an invalid request.

[9432cd65-9f88-4bc6-8ad6-72e5ab1c730d]

I suspect this bug will sit here languishing without action, for various reasons:

I suspect this kind of discussions piss off readers of tickets, but I'll continue, as I do not see any other useful public medium at hand right now.

-- start offtopic --

1) From other doc discussion, I assume you won’t be able to propose a patch.

Right. I do not feel comfortable with Python workflow - now that I have several dozens of unfinished patches - they start to conflict with changes in repository. Conflict resolution takes a lot of time and I can't afford maintaining a separate copy of Python checkout for every patch. It also takes too long to setup test environment and execute tests. There is a lot of yak shaving involved between:

1. make ticket
2. find source
3. make patch
4. test patch
5. attach patch
6. refresh patch
7. test patch
8. attach patch ...

I've already explained it somewhere in more detail. A pity it is lost.

I am waiting for Mercurial 1.6 to try anchored MQ. Perhaps then I will be able to revisit Python contribution process.

2) There is no dedicated maintainer for http or cgi.

I can not be. pydotorg tools suxx tremendously and I do not feel inspired by wasting time trying to fish required information. To be a maintainer I need:

1. separate commit notifications for the module with ability to reply to dedicated review group
2. separate bug tracker category for my module with giving users ability to change every property of it
3. bug tracker timeline for the module that includes ticket changes, wiki edits, commits and everything else. Filtered.
4. roadmap page with Google Wave content for collaborations
5. dashboard page with links to all the above

Look at Trac Hacks for a minimum acceptable example of a tool that is able to persuade me to become a stdlib module developer. Sorry for not able to compile this into a report for EuroPython.

3) CGI is a low-level, archaic, inefficient interface.

stdlib doesn't propose anything better.

-- end offtopic --

4) The cgi server has grave bugs like this one (from the doc): “CGI scripts run by the CGIHTTPRequestHandler class cannot execute redirects (HTTP code 302), because code 200 (script output follows) is sent prior to execution of the CGI script.”

It would be nice if this also clarify if it is the bug of Python class or a limitation of CGI protocol.

[pitrou]

Conflict resolution takes a lot of time and I can't afford maintaining a separate copy of Python checkout for every patch

Then try various hg features such as named branches, or bookmarks, or mq, or pbranch, etc. (or any SVN-facing tool you would like, including git-svn, bzr-svn, etc.)

To be a maintainer I need: [snip]

Most people in most open source projects seem perfectly content without such an artillery of sophisticated tools/gadgets. While the workflow can always be improved, it is not obvious to me that your requirements are in any way reasonable, or even serious ("serious" as in "this is the only reasonable way one can work efficiently on Python" -- plenty of people, almost all of them unpaid volunteers, seem to disagree).

By the way, the first thing needed to qualify as a maintainer would be to *prove* that you are up to the task. Not to have a bunch of nifty tools. In other words, you can't just come and say "hey, I'd like to be a maintainer" and expect this request to be granted automatically.

[9432cd65-9f88-4bc6-8ad6-72e5ab1c730d]

> Conflict resolution takes a lot of time > and I can't afford maintaining a separate copy of Python checkout for > every patch

Then try various hg features such as named branches, or bookmarks, or mq, or pbranch, etc. (or any SVN-facing tool you would like, including git-svn, bzr-svn, etc.)

pbranch is the next in my list, still do not have time to dig all these tools. For now I have these unsolved workflow problems:

1. patches are not tied to specific bug ticket (can only be manually uploaded)
2. I would like to receive feedback on patches inline (like in Mercurial list)
3. I would like to see all the code related to patch (source, tests, docs) in one place
4. Edit, preview and update docs patches online
5. Download patched source and test in one step, execute in the other

> To be a maintainer I need: [snip]

Most people in most open source projects seem perfectly content without such an artillery of sophisticated tools/gadgets.

You account only people who found they way to be able to contribute. Most people didn't. If you can calculate an average indicator of active Python contributors, I will say that it can be improved by 50% only by means of well aligned toolset.

While the workflow can always be improved, it is not obvious to me that your requirements are in any way reasonable, or even serious ("serious" as in "this is the only reasonable way one can work efficiently on Python" -- plenty of people, almost all of them unpaid volunteers, seem to disagree).

I never said "this is the only reasonable way one can work efficiently on Python". I said that "there is no reasonable way one can work efficiently on Python and I am trying to find one". Feel the difference.

By the way, the first thing needed to qualify as a maintainer would be to *prove* that you are up to the task. Not to have a bunch of nifty tools. In other words, you can't just come and say "hey, I'd like to be a maintainer" and expect this request to be granted automatically.

Ok. Let me try to express it in English once more: search: To be a maintainer I need: replace: To be willing to become a maintainer I need:

[pitrou]

pbranch is the next in my list, still do not have time to dig all these tools. For now I have these unsolved workflow problems: [...]

That's a lot of things which others do not perceive as important or even desireable. Chances are you are going to have to implement them yourself if you really want them. In any case, just complaining won't change anything.

Ok. Let me try to express it in English once more: search: To be a maintainer I need: replace: To be willing to become a maintainer I need:

Nobody proposed you to become a maintainer, so this is still besides the point. First contribute significantly, and then we'll see.

[9432cd65-9f88-4bc6-8ad6-72e5ab1c730d]

That's a lot of things which others do not perceive as important or even desireable. Chances are you are going to have to implement them yourself if you really want them. In any case, just complaining won't change anything.

I am just trying to answer why I can't contribute patches myself. Hope the idea to put workflow first after getting enough experience over past year was clear. I work on this workflow alone. If smb. would also feel that is it a more important problem than immediate patch - I'd be glad to collaborate.

> Ok. Let me try to express it in English once more: > search: To be a maintainer I need: > replace: To be willing to become a maintainer I need:

Nobody proposed you to become a maintainer, so this is still besides the point. First contribute significantly, and then we'll see.

Can you estimate my contributions so far? I suspect I should stop wasting time if there are aren't any.

[pitrou]

Le jeudi 17 juin 2010 à 13:22 +0000, anatoly techtonik a écrit :

> That's a lot of things which others do not perceive as important or even > desireable. Chances are you are going to have to implement them yourself > if you really want them. In any case, just complaining won't change > anything.

I am just trying to answer why I can't contribute patches myself.

Thank you, I think you have made your point. Now I suggest you propose patches to improve the workflow on the relevant mailing-list(s) or issue tracker.

[merwok]

I’m sorry to have launched this thread. I hadn’t thought that Senthil is doing a lot of good work on HTTP and URI-related modules, and I wanted to express my feeling that this bug would not get fixed without someone proposing a patch. I didn’t want to imply that the request was not valid nor to discourage bug reporters. If I did, I sincerely apologize.

To address the issues Anatoly raised before I stop being off-topic:

1) Patch submission: You can already use Mercurial to prepare patches (bare Mercurial, MQ or pbranch, on top of a Subversion checkout or Mercurial clone (code.python.org/hg, kindly maintained by Antoine).

2) No maintainer for CGI: The term “maintainer” is explained at the top of the Misc/maintainers.rst file, it means a core developer taking special care of one area or module. All core developpers are collectively maintaining the whole stdlib; a module without a dedicated maintainer is *not* unmaintained.

3) Nothing better than CGI in stdlib: BaseHTTPServer is handy for quick testing; wsgiref is okay for quick testing of WSGI applications. Third-party servers have different design goals and advantages for various classes of users.

4) The header thing is a bug; I’ll search whether it’s already reported.

5) Current workflow seems good to the vast majority of contributors. I’ve been contributing for a few months and found the workflow reasonable and working, like a lot of people. That said, a Web UI for doc changes with live preview may be a good way to let non-programmers propose fixes; please open a feature request on Sphinx’ tracker (on Bitbucket) or ask for opinions on docs@python.org. Again, we’re all volunteers here, so “you should do X” works a lot less than “I want to do X”.

I hope I have provided some hints and data points; I do not wish this off-topic discussion to continue. Like Antoine said, we now understand your viewpoint, and your suggestions for improvement would be more fruitful on relevant mailing lists. Regards

[83d2e70e-e599-4a04-b820-3814bbdb9bef]

@Senthil Kumaran/orsenthil can you pick this up as implied in msg107919?

[AA-Turner]

CGIHTTPServer was removed in Python 3 (PEP-3108), and the cgi module will be removed in Python 3.13 (PEP-594).

A