[issue214532] cgi + .. + xml-data

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210661] cgi parsing of query strings (PR#356)

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue475538] os.system() and cgi

[admin]

Change by admin :


--
github: None -> 35417

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue473586] SimpleXMLRPCServer - fixes and CGI

[admin]

Change by admin :


--
github: None -> 35379

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue453691] CGI: NEW: methods getfirst(), getlist()

[admin]

Change by admin :


--
github: None -> 35021

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue214532] cgi + .. + xml-data

[admin]

Change by admin :


--
github: None -> 33128

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue452174] cgi: new methods: getfirst(), getlist()

[admin]

Change by admin :


--
github: None -> 34990

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue229788] cgi module. FieldStorage class returns keys blank fields.

[admin]

Change by admin :


--
github: None -> 33781

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue224038] CGI : Uploaded file is whole stored in memory

[admin]

Change by admin :


--
github: None -> 33530

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue224038] CGI : Uploaded file is whole stored in memory

[admin]

Change by admin :


--
github: None -> 33530

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210661] cgi parsing of query strings (PR#356)

[admin]

Change by admin :


--
github: None -> 32731

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11352] Update cgi module doc

[Irit Katriel]

Irit Katriel  added the comment:

cgi is deprecated as per PEP 594, so there won't be further enhancements to it.

--
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue11352>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11352] Update cgi module doc

[Irit Katriel]

Change by Irit Katriel :


--
priority: high -> normal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23952] cgi: Document the 'maxlen' member of the cgi module

[Ethan Furman]

Change by Ethan Furman :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23952] cgi: Document the 'maxlen' member of the cgi module

[Ethan Furman]

Ethan Furman  added the comment:


New changeset 6c4e44ef8ab550f846ba056d4561efb8256b8eab by Hugo van Kemenade in 
branch 'main':
bpo-23952: Document cgi module's maxlen variable (GH-30338)
https://github.com/python/cpython/commit/6c4e44ef8ab550f846ba056d4561efb8256b8eab


--

___
Python tracker 
<https://bugs.python.org/issue23952>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23952] cgi: Document the 'maxlen' member of the cgi module

[Ethan Furman]

Change by Ethan Furman :


--
nosy: +ethan.furman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23952] cgi: Document the 'maxlen' member of the cgi module

[Hugo van Kemenade]

Change by Hugo van Kemenade :


--
keywords: +patch
nosy: +hugovk
nosy_count: 4.0 -> 5.0
pull_requests: +28550
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/30338

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23952] cgi: Document the 'maxlen' member of the cgi module

[Yatin Kanetkar]

Change by Yatin Kanetkar :


--
nosy: +yatink

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45650] cgitb does not emit CGI headers when format='text'

[Eric V. Smith]

Eric V. Smith  added the comment:

Having not heard back about a use case for this, I'm going to close it. If you 
want to move this forward, I suggest proposing it on the python-ideas mailing 
list.

--
resolution:  -> rejected
stage:  -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11352] Update cgi module doc

[Vishal Pandey]

Vishal Pandey  added the comment:

i am working on it. will submit a PR soon.

--
nosy: +vishalpandeyvip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11352] Update cgi module doc

[Irit Katriel]

Change by Irit Katriel :


--
type:  -> enhancement
versions: +Python 3.11 -Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11352] Update cgi module doc

[Irit Katriel]

Irit Katriel  added the comment:

Marking as easy. What needs to be done here is to review the patches and see if 
there are any doc improvements in them worth having. Then make a PR.

--
keywords: +easy, newcomer friendly

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11352] Update cgi module doc

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11352] Update cgi module doc

[Glenn Linderman]

Glenn Linderman  added the comment:

First I would have to learn how GitHub works, and how PRs work.  And I haven't 
found time for that, as yet.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11352] Update cgi module doc

[Irit Katriel]

Irit Katriel  added the comment:

Would you like to work on a GitHub PR with these changes?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11352] Update cgi module doc

[Glenn Linderman]

Glenn Linderman  added the comment:

Seems like another example of the CGI module not getting much support. While I 
haven't looked at all the details of the patches, it seems that several people 
have contributed enhancements or clarifications. and it would be a shame to 
discard them rather than merge the submissions... but it seems no one with 
authority wants to support CGI.

--
status: pending -> open

___
Python tracker 
<https://bugs.python.org/issue11352>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11352] Update cgi module doc

[Irit Katriel]

Irit Katriel  added the comment:

Since there was no activity on this for 6-7 years and it's not describing a 
specific issue, I will close this in a couple of weeks unless someone asks me 
not to.

--
nosy: +iritkatriel
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23952] cgi: Document the 'maxlen' member of the cgi module

[Irit Katriel]

Change by Irit Katriel :


--
Removed message: https://bugs.python.org/msg406733

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23952] cgi: Document the 'maxlen' member of the cgi module

[Irit Katriel]

Irit Katriel  added the comment:

I

--
components: +Library (Lib)
keywords: +easy, newcomer friendly
nosy: +iritkatriel
type:  -> enhancement
versions: +Python 3.11 -Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45650] cgitb does not emit CGI headers when format='text'

[Eric V. Smith]

Change by Eric V. Smith :


--
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45650] cgitb does not emit CGI headers when format='text'

[Eric V. Smith]

Eric V. Smith  added the comment:

I would think the use case for 'text' is to not print the output to a web page, 
so you wouldn't want the headers. The documentation says that cgitb was 
generalized to not only produce output for web pages. The 'text' format 
provides this generalization.

Changing to an enhancement request for 3.11. We can't change the 'text' format 
because it would break existing code. so this is really an enhancement request 
for a new format. But I don't see what the use case would be, so I don't think 
it would be accepted.

What's the case where you need this functionality? How is the 'html' format 
unacceptable?

--
nosy: +eric.smith
type: behavior -> enhancement
versions:  -Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45650] cgitb does not emit CGI headers when format='text'

[Kier Davis]

New submission from Kier Davis :

## Context ##

* Python is executing a script on behalf of a web server (e.g. Apache httpd) 
following the CGI protocol.
* cgitb is enabled and configured to use the 'text' format.
* An unhandled exception occurs before any CGI response headers have been 
emitted.


## Expected behaviour ##

A valid response is returned from the CGI script to the web server and 
ultimately to the client.


## Observed behaviour ##

The response is rejected by the web server because it does not begin with a 
valid CGI header block.

[cgi:error] [pid x] [client xxx.xxx.xxx.xxx:x] malformed header 
from script 'web.py': Bad header: A problem occurred in a Pyt

Any traceback info included (if display=1) gets discarded and the web server 
returns its own Internal Server Error response instead.


## Comments ##

A valid response is observed if format='html'. This bug only concerns 
format='text'.
The behaviour is the same regardless of whether display=0 or display=1.

I imagine this is because cgitb.reset (which emits the headers) is only called 
when format='html'.
We could resolve this by always calling cgitb.reset regardless of the format, 
or by introducing separate text-format and HTML-format versions of cgitb.reset.
I'm happy to prepare a patch if you agree on the approach.

--
components: Library (Lib)
files: repro_cgitb_not_emitting_headers_in_text_mode.py
messages: 405198
nosy: kierdavis
priority: normal
severity: normal
status: open
title: cgitb does not emit CGI headers when format='text'
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 
3.9
Added file: 
https://bugs.python.org/file50409/repro_cgitb_not_emitting_headers_in_text_mode.py

___
Python tracker 
<https://bugs.python.org/issue45650>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31382] CGI upload error when file ~< 10kb

[Irit Katriel]

Irit Katriel  added the comment:

There isn't enough information here to understand what your issue is. If you 
are still having this problem on a current python version (3.9+), please create 
a new issue and provide instructions how to reproduce it and information about 
the environment in which you are seeing it.

--
nosy: +iritkatriel
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41139] cgi uses the locale encoding for log files

[Inada Naoki]

Change by Inada Naoki :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41139] cgi uses the locale encoding for log files

[Inada Naoki]

Inada Naoki  added the comment:


New changeset e52ab42cedd2a5ef4c3c1a47d0cf96a8f06d051f by Inada Naoki in branch 
'master':
bpo-41139: Deprecate `cgi.log()` (GH-25625)
https://github.com/python/cpython/commit/e52ab42cedd2a5ef4c3c1a47d0cf96a8f06d051f


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8077] [Windows] cgi handling of POSTed files is broken in Windows

[STINNER Victor]

Change by STINNER Victor :


--
components: +Windows -Library (Lib)
nosy: +paul.moore, steve.dower, tim.golden, zach.ware -vstinner
title: cgi handling of POSTed files is broken in Windows -> [Windows] cgi 
handling of POSTed files is broken in Windows

___
Python tracker 
<https://bugs.python.org/issue8077>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8077] cgi handling of POSTed files is broken in Windows

[Senthil Kumaran]

Change by Senthil Kumaran :


--
pull_requests: +24343
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/25652

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8077] cgi handling of POSTed files is broken in Windows

[Senthil Kumaran]

Change by Senthil Kumaran :


--
title: cgi handling of POSTed files is broken -> cgi handling of POSTed files 
is broken in Windows
versions: +Python 3.10 -Python 3.2, Python 3.3

___
Python tracker 
<https://bugs.python.org/issue8077>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3609] does parse_header really belong in CGI module?

[Senthil Kumaran]

Change by Senthil Kumaran :


--
stage: needs patch -> resolved
status: languishing -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3609] does parse_header really belong in CGI module?

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Closing this age old bug in favor of fixing it as part of issue23498.

--
resolution:  -> wont fix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41139] cgi uses the locale encoding for log files

[Inada Naoki]

Change by Inada Naoki :


--
keywords: +patch
pull_requests: +24324
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25625

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41139] cgi uses the locale encoding for log files

[Inada Naoki]

Inada Naoki  added the comment:

+1 for removing.
But let's emit DeprecationWarning for now, and remove it later.

--
components: +Library (Lib)
versions:  -Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41139] cgi uses the locale encoding for log files

[Inada Naoki]

Change by Inada Naoki :


--
nosy: +methane

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Senthil Kumaran]

Senthil Kumaran  added the comment:

I spent some time reviewing and researching the specification. It also says

   The server is not required to create meta-variables for all the
   header fields that it receives.  

And this in issue, open since 2010, we have issue two different set of 
variables one from Apache and from Nginx. So, it Is not certain if http.server 
should be alinged it any or all, and plus if anything is required.

The discussion on QUERY_STRING was noted, but as Pierre pointed out it was set 
too

for k in ('QUERY_STRING', 'REMOTE_HOST', 'CONTENT_LENGTH',
  'HTTP_USER_AGENT', 'HTTP_COOKIE', 'HTTP_REFERER'):
env.setdefault(k, "")

For cosmetic purpose, I could remove the existing if condition - 
https://github.com/python/cpython/pull/23604

I am not sure if we need to add other variables with an empty string value for 
any reason. 

As a maintainer, I think, we should close this issue.

If there is a bug report, like issue5054, then that is a valid issue, and we 
should fix it.  If there any specific issues raised with parsing or lack of 
"required" meta variable that caused the application to break, even that could 
be fixed.

I am closing this issue with a cosmetic change that stemmed out from the 
discussion - https://github.com/python/cpython/pull/23604

--
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Senthil Kumaran]

Change by Senthil Kumaran :


--
keywords: +patch
pull_requests: +22473
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23604

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Hello Maarten,

> Using cgitb, I found out that the webdriver expects the environment variable 
> `HTTP_X_URWID_METHOD` to be set. The javascript sets the "X-Urwid-Method" 
> header (using XmlHttpRequest), but these are not visible by the CGI python 
> script.

> So some scripts extra Meta-Variables neet to be set

Thanks for your comment on this old issue. The topic under discussion was about 
some existing "more standard" CGI variables than special meta variables. 

Even if the first standard CGI variables issue get exposed, I doubt the meta 
variables will get added. I will think about considering the minimal change 
required to accomplish the task and close the issue.

--
stage:  -> needs patch

___
Python tracker 
<https://bugs.python.org/issue10486>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Maarten]

Maarten  added the comment:

The CGI examples of urwid (see 
http://urwid.org/manual/displaymodules.html#cgi-web-display-module-web-display) 
don't work on http.server because of missing meta variables.

Using cgitb, I found out that the webdriver expects the environment variable 
`HTTP_X_URWID_METHOD` to be set. The javascript sets the "X-Urwid-Method" 
header (using XmlHttpRequest), but these are not visible by the CGI python 
script.

So some scripts extra Meta-Variables neet to be set.

I think section 4.1.18 applied because it is a http header that is being set. 
The sections says that these meta-variables are optional though.

I argue that having access to extra headers is useful.

--
nosy: +maarten

___
Python tracker 
<https://bugs.python.org/issue10486>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41398] cgi module, parse_multipart fails

[Jeffrey Kintscher]

Change by Jeffrey Kintscher :


--
nosy: +Jeffrey.Kintscher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41398] cgi module, parse_multipart fails

[Guido van Rossum]

Guido van Rossum  added the comment:

Could you submit a PR then? I don't think I've looked at that module in 20 
years.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41398] cgi module, parse_multipart fails

[Magnus Johnsson]

Magnus Johnsson  added the comment:

No, of course not.
The request is completely valid. Python's cgi library parses it wrong.

The 'resolution' that needs to be done is to fix it in python's source.
That, and the libraries that depend on it, like twisted, probably needs to move 
away from using python's cgi library at all, given the age of this bug.

As it stands, we have had to patch 16 separate calls, and will be moving away 
from the twisted-based server over it anyway, since it seems sketchy.

Going to have a peek at the source, but I am a bit hesitant to touch things 
that have that large a userbase.

--

___
Python tracker 
<https://bugs.python.org/issue41398>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41398] cgi module, parse_multipart fails

[Guido van Rossum]

Guido van Rossum  added the comment:

So per the stackoverflow explanation you shouldn’t do that? Should we close 
this?

--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41398] cgi module, parse_multipart fails

[Magnus Johnsson]

Magnus Johnsson  added the comment:

https://github.com/yohanboniface/falcon-multipart/issues/8

It would seem that the same issue pops up elsewhere. We do indeed set the 
content-type, as per the default examples for unity.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41398] cgi module, parse_multipart fails

[SilentGhost]

Change by SilentGhost :


--
components: +Library (Lib)
nosy: +ethan.furman
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41398] cgi module, parse_multipart fails

[Magnus Johnsson]

New submission from Magnus Johnsson :

When using the cgi module, parse_multipart fails with the supplied file with 
the error:

Invalid boundary in multipart form: b''

A sample program that demonstrates the error:
import cgi
f = open("60_Request.txt", "r")
print(cgi.parse_multipart(f, {'boundary': 
b'BgTzK0jM20UH01naJdsmAWUj7sqqeoikGZvh3mo9', 'CONTENT-LENGTH': 3992}))

This affects for instance Twisted, and all its dependencies.

--
files: 60_Request.txt
messages: 374307
nosy: Magnus Johnsson
priority: normal
severity: normal
status: open
title: cgi module, parse_multipart fails
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49340/60_Request.txt

___
Python tracker 
<https://bugs.python.org/issue41398>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10879] cgi memory usage

[Inada Naoki]

Change by Inada Naoki :


--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10879] cgi memory usage

[Rhodri James]

Change by Rhodri James :


--
nosy:  -Rhodri James

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41139] cgi uses the locale encoding for log files

[Rhodri James]

Change by Rhodri James :


--
nosy:  -Rhodri James

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41139] cgi uses the locale encoding for log files

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Available options:

1. Do nothing (keep cgi.log() and continue to use the default encoding for 
open()).
2. Remove cgi.log(). I think that the deprecation period is not needed because 
the function is not documented, is not imported by star-import, and is not 
shown in help.
3. Make cgi.log() using UTF-8 for open(). This may break some existing code if 
cgi.log() is ever used.
4. Completely rewrite cgi.log() using the logging module.

In all options except 2 cgi.log() needs to be documented and advertised as a 
new feature. And we should ask ourself: do we need this feature? Does it have 
advantages over the logging package?

It was more visible in 2.0. But since adding __all__ in 2.1 (in 
e99d5ea25ba994491c773d9b5872332334ccd1c5) it is a hidden feature.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41139] cgi uses the locale encoding for log files

[శ్రీనివాస్ రెడ్డి తాటిపర్తి]

Srinivas  Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) 
 added the comment:

My bad. I meant cgi.log(), I pressed submit changes in a hurry.

+1 for utf-8.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41139] cgi uses the locale encoding for log files

[Ethan Furman]

Ethan Furman  added the comment:

Which functionality?

- cgi.log()

- opening with current locale

I don't mind keeping the function, but if the file isn't already opened I think 
using UTF-8 is an appropriate choice.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41139] cgi uses the locale encoding for log files

[శ్రీనివాస్ రెడ్డి తాటిపర్తి]

Srinivas  Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) 
 added the comment:

I am for keeping this functionality. Unless others in this nosy list think 
otherwise.

--
nosy: +thatiparthy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41139] cgi uses the locale encoding for log files

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

The cgi module provides undocumented feasibility for logging. cgi.log() formats 
log message and appends it to the log file with name specified by cgi.logfile 
if it was not empty before the first use of cgi.log().

One of problems is that it uses the locale encoding for log file. Therefore the 
result depends on the locale at the moment of the first use of cgi.log().

We can fix this by using some fixed encoding (UTF-8). Or maybe just remove this 
undocumented feature.

--
messages: 372462
nosy: Rhodri James, ethan.furman, serhiy.storchaka, vinay.sajip
priority: normal
severity: normal
status: open
title: cgi uses the locale encoding for log files
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue41139>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26527] CGI library - Using unicode in header fields

[Martin Panter]

Martin Panter  added the comment:

I’m not an expert on the topic, but it sounds like this might be a duplicate of 
Issue 23434, which has more discussion.

--
nosy: +martin.panter
resolution:  -> duplicate
status: open -> pending
superseder:  -> support encoded filename in Content-Disposition for HTTP in 
cgi.FieldStorage

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10879] cgi memory usage

[Rhodri James]

Change by Rhodri James :


--
nosy: +Rhodri James, ethan.furman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: PEP 594 cgi & cgitb removal

[Peter J. Holzer]

On 2019-05-25 23:45:06 +0200, Roel Schroeven wrote:
> Jon Ribbens via Python-list schreef op 25/05/2019 om 21:00:
> > On 2019-05-25, Michael Torrie  wrote:
> > > On 05/24/2019 04:27 AM, Jon Ribbens via Python-list wrote:
> > > > Sorry, in what sense do you mean "Serverless is CGI"?
> > > > 
> > > > As far as I can tell, it's just a script to automatically upload
> > > > bits of code into various cloud providers, none of which use CGI.
> > > 
> > > Not really.  Serverless just means stateless web-based remote procedure
> > > calls.  This is by definition what CGI is.
> > 
> > No, it isn't. CGI is a specific API and method of calling a program
> > in order to serve a web request. It isn't a shorthand for "any
> > web-based remote procedure call".
> 
> More specifically, with CGI the webserver starts a new process for every
> single request. That's bad enough for a light C program, but it's certainly
> not a good idea to start a whole new Python process for every request. At
> least not for any production website or web service that serves any real
> amount of traffic.

I strongly disagree with this. A minimal Python script using the cgi
package takes between 50 and 80 milliseconds on my (not very fast)
private server. Assuming a script which does anything useful takes about
100 milliseconds, that's still 

a) a shorter response time than a lot of websites with persistent
servers have
b) fast enough not be a bottleneck on the vast majority of web sites.
Yes, you cannot run Facebook on CGI, but most websites aren't
Facebook. I doubt we have even one website which gets close to 10 
requests to dynamic content per second. Much less 10 requests per
second per core.

I don't use CGI very much these days (and when I do, I use Perl - old
habits die hard), but performance isn't the reason.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Robin Becker]

...


More specifically, with CGI the webserver starts a new process for every single request. That's bad enough for a light C program, 
but it's certainly not a good idea to start a whole new Python process for every request. At least not for any production website 
or web service that serves any real amount of traffic.


That is, for those who didn't know, the reason why CGI fell out of use quite 
some time ago.



Well I'm afraid I cannot agree with that reasoning. ReportLab used cgi exactly because it starts a new process; most of the 
reports that are generated take more than a second to generate so the startup time is of less importance. Starting up in a clean 
state is of importance because the sharing of resources across different reports often leads to buggy report code such as relying 
on an earlier report to load fonts, define colours etc etc. This could perhaps have been done with multiple interpreters eg 
mod_python, but I think the isolation there is not perfect especially with C extensions.


It might be that the new 'cgi' doesn't use the older api and in that sense we could just use wsgi or whatever the new interface 
is, but I would still use cgitb to provide nicely formatted traceback html.

--
Robin Becker

--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Rhodri James]

On 24/05/2019 21:23, Terry Reedy wrote:
I am responding to Paul indirectly because his post did not show up on 
the gmane mirror.



Paul Rubin :



It also makes me ask why the Python team keeps
adding new stuff if it can't even keep the old stuff running.


Because the new stuff is expected to be more useful to more people than 
some of the old modules.  The module proposed for deletion are all or 
most all more than 20 years old, before there was a PyPI.  Some, like 
cgi and cgitb were legitimately put in the stdlib.  Others were 
specialist modules that today would not go in the stdlib.


Does anyone really think that gopherlib should still be in the stdlib, 
and that core developers should have to update its docs to explain it to 
newbies today?


I would want a better reason than "I don't wanna" to remove something 
from stdlib, much as I would want a better reason than "I want it" to 
add something.  I agree that case is pretty much self-evident with 
gopherlib, which honestly would had trouble convincing me it should be 
included in the first place.  I don't think it is at all self-evident 
for cgi and cgitb, even if I wouldn't have written them like that myself ;-)


My question is why people who value and understand old modules don't 
volunteer more to help keep them up to date.


As I said (and was apparently misinterpreted), I am considering it.

--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Roel Schroeven]

Jon Ribbens via Python-list schreef op 25/05/2019 om 21:00:

On 2019-05-25, Michael Torrie  wrote:

On 05/24/2019 04:27 AM, Jon Ribbens via Python-list wrote:

Sorry, in what sense do you mean "Serverless is CGI"?

As far as I can tell, it's just a script to automatically upload
bits of code into various cloud providers, none of which use CGI.


Not really.  Serverless just means stateless web-based remote procedure
calls.  This is by definition what CGI is.


No, it isn't. CGI is a specific API and method of calling a program
in order to serve a web request. It isn't a shorthand for "any
web-based remote procedure call".


More specifically, with CGI the webserver starts a new process for every 
single request. That's bad enough for a light C program, but it's 
certainly not a good idea to start a whole new Python process for every 
request. At least not for any production website or web service that 
serves any real amount of traffic.


That is, for those who didn't know, the reason why CGI fell out of use 
quite some time ago.


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Marko Rauhamaa]

Jon Ribbens :
> On 2019-05-25, Michael Torrie  wrote:
>> Not really. Serverless just means stateless web-based remote
>> procedure calls. This is by definition what CGI is.
>
> No, it isn't. CGI is a specific API and method of calling a program in
> order to serve a web request. It isn't a shorthand for "any web-based
> remote procedure call".

Both of you make relevant and insightful statements.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Jon Ribbens via Python-list]

On 2019-05-25, Michael Torrie  wrote:
> On 05/24/2019 04:27 AM, Jon Ribbens via Python-list wrote:
>> Sorry, in what sense do you mean "Serverless is CGI"?
>> 
>> As far as I can tell, it's just a script to automatically upload
>> bits of code into various cloud providers, none of which use CGI.
>
> Not really.  Serverless just means stateless web-based remote procedure
> calls.  This is by definition what CGI is.

No, it isn't. CGI is a specific API and method of calling a program
in order to serve a web request. It isn't a shorthand for "any
web-based remote procedure call".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Michael Torrie]

On 05/24/2019 04:27 AM, Jon Ribbens via Python-list wrote:
> On 2019-05-23, Gunnar Þór Magnússon  wrote:
>>> nginx is the current hotness. CGI has not been hotness since the
>>> mid 90s.
>>
>> Serverless is the new hotness, and serverless is CGI. Technology is
>> cyclical.
> 
> Sorry, in what sense do you mean "Serverless is CGI"?
> 
> As far as I can tell, it's just a script to automatically upload
> bits of code into various cloud providers, none of which use CGI.

Not really.  Serverless just means stateless web-based remote procedure
calls.  This is by definition what CGI is.  Only now you can click a
button and put your cgi script on any cloud provider you want and get
billed by how much cpu and network bandwidth your little cgi script
uses.  So basically the cool kids have reinvented CGI.  And instead of
calling them scripts, they call them functions.

Serverless is an unfortunate name.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Michael Torrie]

On 05/24/2019 01:24 PM, Marko Rauhamaa wrote:
> There's a programming language arms race. Python wants to beat Java, C#
> and go in the everything-for-everybody game. Python developers seem to
> take the popularity of the language as proof of success. Pride goes
> before the fall.

I don't see this at all.  Python is useful.  Period.  And it may be
popular too.  I don't actually think the core devs are focused much at
all on winning a popularity contest.  Besides, who cares about C# or
Java.  It's not a zero sum game.  Features are being added that people
who use Python require, or that the core devs think are useful or cool.
Other languages are also evolving similar features.  Async stuff is not
simply to compete with C#.  It's seen as a necessary feature for certain
types of development that are popular (needed?) right now.

The only thing that worries me is that open source and free software
projects in general seem to be in decline as their core developers age
out and generally get tired or change their priorities.  We don't seem
to be attracting replacement talent.  Perhaps the next generations are
less idealistic, or more likely they have less money and thus less time
to donate.  I could maybe fall into that category.  I'm older now than
when I was first exposed to Linux, and I have a lot less time.

Corporate open source software seems to be a growing phenomenon.  While
I welcome companies being open and liberal with their source code and
projects, it does worry me just a bit.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Terry Reedy]

I am responding to Paul indirectly because his post did not show up on 
the gmane mirror.



Paul Rubin :



It also makes me ask why the Python team keeps
adding new stuff if it can't even keep the old stuff running.


Because the new stuff is expected to be more useful to more people than 
some of the old modules.  The module proposed for deletion are all or 
most all more than 20 years old, before there was a PyPI.  Some, like 
cgi and cgitb were legitimately put in the stdlib.  Others were 
specialist modules that today would not go in the stdlib.


Does anyone really think that gopherlib should still be in the stdlib, 
and that core developers should have to update its docs to explain it to 
newbies today?


My question is why people who value and understand old modules don't 
volunteer more to help keep them up to date.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Marko Rauhamaa]

Paul Rubin :
> Stéphane Wirtel  writes:
>> Not a massive effort, but we are limited with the resources.
>
> I keep hearing that but it makes it sound like Python itself is in
> decline. That is despite the reports that it is now the most popular
> language in the world. It also makes me ask why the Python team keeps
> adding new stuff if it can't even keep the old stuff running. I'd urge
> a more conservative approach to this stuff.

Generally, my feelings are the same as yours, and I'm saddened by the
steady decline of one of my all-time favorite programming languages.

However, the Python developers can do whatever they want with their free
time. Of course, it's much more exciting to add new bells and whistles
to a language than maintain some 1980's legacy. So I can't make any
demands for Python.

> People who want bleeding edge advances in language technology should
> use Haskell. People who want amorphous crap-laden ecosystems that keep
> changing and breaking should use Javascript/NPM. Those who want to be
> assimilated by the Borg and get aboard an entire micromanaged
> environment have Goland or (even worse) Java. Python for a while
> filled the niche of being a not too cumbersome, reasonably stable
> system for people trying to get real-world tasks done and wanted a
> language that worked and stayed out of the way.

There's a programming language arms race. Python wants to beat Java, C#
and go in the everything-for-everybody game. Python developers seem to
take the popularity of the language as proof of success. Pride goes
before the fall.

> Please don't abandon that.

I'm afraid the damage is already done.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[D'Arcy Cain]

On 2019-05-22 03:51, Robin Becker wrote:
> In PEP 594 t has been proposed that cgi & cgitb should be removed. I
> suspect I am not the only person in the world that likes using cgi and
> cgitb.

I use both heavily.  Just another data point.  I wasn't going to respond
with a "Me too" except that I saw posts suggesting that few people are
chiming in.

-- 
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Stéphane Wirtel]

On 05/23, Rhodri James wrote:

On 22/05/2019 19:29, Terry Reedy wrote:
One of the factors being considered in removal decisions is the 
absence of anyone willing to list themselves in the expert's list

https://devguide.python.org/experts/
as a maintainer for a module.

At the moment, 3 other people have objected to the removal of these 
modules.  I suspect that at least 2 of you 4 are at least as 
technically qualified to be a core developer as I am.  A request to 
become the maintainer of cgi and cgitb *might* affect the decision.


A quick read-through of the modules (I am supposed to be working right 
now) suggests that maintaining them wouldn't be a massive effort. 
Definitely something to think about.

Not a massive effort, but we are limited with the resources.

--
Stéphane Wirtel - https://wirtel.be - @matrixise
--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Jon Ribbens via Python-list]

On 2019-05-23, Gunnar Þór Magnússon  wrote:
>> nginx is the current hotness. CGI has not been hotness since the
>> mid 90s.
>
> Serverless is the new hotness, and serverless is CGI. Technology is
> cyclical.

Sorry, in what sense do you mean "Serverless is CGI"?

As far as I can tell, it's just a script to automatically upload
bits of code into various cloud providers, none of which use CGI.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Gunnar Þór Magnússon]

> nginx is the current hotness. CGI has not been hotness since the mid 90s.

Serverless is the new hotness, and serverless is CGI. Technology is cyclical.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Rhodri James]

On 22/05/2019 19:29, Terry Reedy wrote:
One of the factors being considered in removal decisions is the absence 
of anyone willing to list themselves in the expert's list

https://devguide.python.org/experts/
as a maintainer for a module.

At the moment, 3 other people have objected to the removal of these 
modules.  I suspect that at least 2 of you 4 are at least as technically 
qualified to be a core developer as I am.  A request to become the 
maintainer of cgi and cgitb *might* affect the decision.


A quick read-through of the modules (I am supposed to be working right 
now) suggests that maintaining them wouldn't be a massive effort. 
Definitely something to think about.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Jon Ribbens via Python-list]

On 2019-05-23, Paul Rubin  wrote:
> dieter  writes:
>> Should "cgi" disappear from the standard library
>
> It's also a concern that cgi may be disappearing from web servers.  Last
> I heard, nginx didn't support it.  That's part of why I still use
> apache, or (local only) even CGIHTTPServer.py.  I don't know what the
> current hotness in httpd's is though.

nginx is the current hotness. CGI has not been hotness since the mid 90s.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[dieter]

Robin Becker  writes:
> In PEP 594 t has been proposed that cgi & cgitb should be removed. I
> suspect I am not the only person in the world that likes using cgi and
> cgitb.

Currently, "Zope" is using "cgi"; it uses "zExceptions" (--> PyPI)
for tracebacks.

Should "cgi" disappear from the standard library, I am quite
confident that "Zope" will get a replacement. "Zope" is known
to be build out of components (i.e. individual packages) which
can be used independently from "Zope" itself (e.g.
"zope.interface", "ZODB", "transaction", ...). Thus, there
is a good chance that there will be an open source, maintained
module supporting core features of the current "cgi" module.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Terry Reedy]

On 5/22/2019 3:51 AM, Robin Becker wrote:
In PEP 594 t has been proposed that cgi & cgitb should be removed. I 
suspect I am not the only person in the world that likes using cgi and 
cgitb.


I suspect that there will be at least one person objecting to each 
removal.  But the underlying issue, at least to me, is that the number 
and complexity of stdlib modules has grown significantly faster than the 
number of active core developers.


One of the factors being considered in removal decisions is the absence 
of anyone willing to list themselves in the expert's list

https://devguide.python.org/experts/
as a maintainer for a module.

At the moment, 3 other people have objected to the removal of these 
modules.  I suspect that at least 2 of you 4 are at least as technically 
qualified to be a core developer as I am.  A request to become the 
maintainer of cgi and cgitb *might* affect the decision.


I filed a bug against cgitb in 2004 with (apparently unacceptable 
patches) that is still unfixed.


I cannot say much without a link.  'Apparently' suggests that it was not 
explicitly rejected.  Was there any review?  Lack of reviews is a 
current bottleneck in merging issues.  Most people are much more willing 
to submit their own code than review that of others.  If you were to 
submit a new, and likely better patch (PR), perhaps others who want to 
keep the modules would review it.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Tim Chase]

On 2019-05-22 08:51, Robin Becker wrote:
> In PEP 594 t has been proposed that cgi & cgitb should be removed.
> I suspect I am not the only person in the world that likes using
> cgi and cgitb.

/me waves from the the back row as another cgi/cgitb user...

-tkc


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[inhahe]

Re cgitb, not sure if this is what you want, but I just came across this
this week:  https://github.com/cknd/stackprinter

On Wed, May 22, 2019 at 3:52 AM Robin Becker  wrote:

> In PEP 594 t has been proposed that cgi & cgitb should be removed. I
> suspect I am not the only person in the world that likes
> using cgi and cgitb.
>
> One of the nice features in cgitb is the ability to get a nice traceback
> with variable values etc etc etc. I have used the
> underlying mechanism to produce better traceback information on several
> occasions and not only in cgi applications.
>
> I filed a bug against cgitb in 2004 with (apparently unacceptable patches)
> that is still unfixed.
>
> Although cgi is claimed to be dead it is still one of the easiest ways to
> get a web service to operate; it is also stateless and
> robust. If cgi and similar are removed from the stdlib python will become
> significantly less charged. These batteries are not dead
> they are pining.
>
> There is some discussion on the python-dev list of moving these allegedly
> dead packages to pypi, but of course that means issues
> of control, where do the sources reside and other politics.
>
> Django has a similar feature to cgitb's output for tracebacks, but is too
> deeply embedded for use elsewhere; is there anything
> suitable elsewhere?
> --
> Robin Becker
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 594 cgi & cgitb removal

[Rhodri James]

On 22/05/2019 08:51, Robin Becker wrote:
In PEP 594 t has been proposed that cgi & cgitb should be removed. I 
suspect I am not the only person in the world that likes using cgi and 
cgitb.


Can I second this?  I just started writing a small CGI application in 
Python, and if cgi and cgitb were going to disappear I would have to 
rewrite it in C or similar.


(No, using something more complex than CGI is not an option.  I'm 
working on an embedded system, and we're watching our RAM usage 
nervously enough already.)


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

PEP 594 cgi & cgitb removal

[Robin Becker]

In PEP 594 t has been proposed that cgi & cgitb should be removed. I suspect I am not the only person in the world that likes 
using cgi and cgitb.


One of the nice features in cgitb is the ability to get a nice traceback with variable values etc etc etc. I have used the 
underlying mechanism to produce better traceback information on several occasions and not only in cgi applications.


I filed a bug against cgitb in 2004 with (apparently unacceptable patches) that 
is still unfixed.

Although cgi is claimed to be dead it is still one of the easiest ways to get a web service to operate; it is also stateless and 
robust. If cgi and similar are removed from the stdlib python will become significantly less charged. These batteries are not dead 
they are pining.


There is some discussion on the python-dev list of moving these allegedly dead packages to pypi, but of course that means issues 
of control, where do the sources reside and other politics.


Django has a similar feature to cgitb's output for tracebacks, but is too deeply embedded for use elsewhere; is there anything 
suitable elsewhere?

--
Robin Becker

--
https://mail.python.org/mailman/listinfo/python-list

[issue16066] Truncated POST data in CGI script on Windows 7

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5340] Change in cgi behavior breaks existing software

[Inada Naoki]

Change by Inada Naoki :


--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9008] CGIHTTPServer support for arbitrary CGI scripts

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11352] Update cgi module doc

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Glenn Linderman]

Glenn Linderman  added the comment:

That's interesting, Pierre, I hadn't really read the RFC carefully, to realize 
that many of the "missing" variables from Apache are HTTP headers, and that 
section 4.1.18 tell how to convert HTTP headers to meta variables.

The code in server.py 3.6 (Sorry, I should check the master branch) picks 
specific HTTP_ headers to include, rather than including them all per the 
rules. Doing the latter would go a long way toward being more compatible with 
Apache. I don't know if Rémi got his NGINX list from source code (looks like 
it) and if maybe NGINX also defines meta variables from the HTTP_ headers, that 
are not listed in the header file he seems to be quoting.

Unless the code has already been improved for Python 3.7, I think there is 
still some work to do to make server.py conform even to the RFC, if not be 
compatible with Apache.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Pierre Quentel]

Pierre Quentel  added the comment:

The QUERY_STRING value is always set by the code at lines 1135-1137 of 
http.server:

for k in ('QUERY_STRING', 'REMOTE_HOST', 'CONTENT_LENGTH',
  'HTTP_USER_AGENT', 'HTTP_COOKIE', 'HTTP_REFERER'):
env.setdefault(k, "")

The RFC for CGI has not evolved since 2004, probably because the technology is 
stable, and also because other, more efficient protocols have been defined to 
avoid the "CGI overhead" (FastCGI for instance).

I think that http.server should only implement the "meta-variables" defined in 
RFC 3875:
- AUTH_TYPE  CONTENT_LENGTH CONTENT_TYPE  GATEWAY_INTERFACE PATH_INFO  
PATH_TRANSLATED QUERY_STRING  REMOTE_ADDR REMOTE_HOST  REMOTE_IDENT REMOTE_USER 
 REQUEST_METHOD SCRIPT_NAME  SERVER_NAME SERVER_PORT  SERVER_PROTOCOL 
SERVER_SOFTWARE. Some of these must always be set (eg QUERY_STRING, 
REQUEST_METHOD, SERVER_NAME...) but for other ones, there are conditions (for 
instance for CONTENT_LENGTH: "The server MUST set this meta-variable if and 
only if the request is accompanied by a message-body entity")
- "protocol-specific meta variables" : for HTTP, variables determined by the 
HTTP request headers such as HTTP_COOKIE (cf section 4.1.18.  Protocol-Specific 
Meta-Variables)

Other meta variables are probably beyond the scope of a module in the standard 
library.

In short, in my opinion the issue can be closed.

--

___
Python tracker 
<https://bugs.python.org/issue10486>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

Hi Glenn, I'm not aware of a document that defines CGI better than the RFC and 
I don't know it enough to disgress from the published standard (even if it is 
not what isdone today as I don't know the current practices enough).

Here is the variables defined by nginx 1.10.3 on Debian:

fastcgi_param  QUERY_STRING   $query_string;
fastcgi_param  REQUEST_METHOD $request_method;
fastcgi_param  CONTENT_TYPE   $content_type;
fastcgi_param  CONTENT_LENGTH $content_length;

fastcgi_param  SCRIPT_NAME$fastcgi_script_name;
fastcgi_param  REQUEST_URI$request_uri;
fastcgi_param  DOCUMENT_URI   $document_uri;
fastcgi_param  DOCUMENT_ROOT  $document_root;
fastcgi_param  SERVER_PROTOCOL$server_protocol;
fastcgi_param  REQUEST_SCHEME $scheme;
fastcgi_param  HTTPS  $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWAREnginx/$nginx_version;

fastcgi_param  REMOTE_ADDR$remote_addr;
fastcgi_param  REMOTE_PORT$remote_port;
fastcgi_param  SERVER_ADDR$server_addr;
fastcgi_param  SERVER_PORT$server_port;
fastcgi_param  SERVER_NAME$server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS200;

Someone that knows CGI better than me may know the way forward

--

___
Python tracker 
<https://bugs.python.org/issue10486>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Glenn Linderman]

Glenn Linderman  added the comment:

Rémi Lapeyre, glad to see your interest here, as this is an old and languishing 
bug.

I would have hoped based on my input, that had there been anyone that was 
maintaining the Python web server code, that they might have done a more 
complete analysis than I did.

I note the document you reference is from 2004 (and I referenced it too), and 
doesn't include mention of the HTTP_COOKIE header, yet that header is 
frequently used in practical web applications. Apache supports it (as noted). 
My point is that it is not clear that conforming to the RFC 3875 from 2004 is 
really sufficient to build a useful web server. While it is true that my 
references to Apache are to a particular implementation, it is a widespread 
implementation, which other implementations attempt to be compatible with, 
indicating that being reasonably compatible with Apache would seem to be a good 
thing for other web server implementations. A few more environment variables 
don't cost a lot, and seem to be useful. I don't know if some or all of the 
additional environment variables implemented by Apache are standardized by RFC 
or other standards, or whether they are common practice, or unique to Apache. 
Nor where such standards might be fonud, but I would hope a maintainer of the 
Python web server would be interested in sorting out such environment variables 
and making that determination, rather than relying on a 14 year old RFC as the 
definitive source, when web technologies have progressed significantly in the 
last 14 years. I would agree that variables that are unique to Apache might not 
want to be implemented, but on the other hand, with other implementations 
following Apache's lead, there may be few that are unique to Apache.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

AUTH_TYPE, CONTENT_LENGTH, CONTENT_TYPE, REMOTE_USER are present

REMOTE_IDENT is not but I'm not sure it's worth adding.

I can send a PR to add REMOTE_HOST and remove the condition for QUERY_STRING.

Otherwise, I don't think the other environment variables should be added, they 
are implementation dependant and not defined in RFC 3875.

Should we close this issue?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

The reference given in 
https://github.com/python/cpython/blob/b36b0a3765bcacb4dcdbf12060e9e99711855da8/Lib/http/server.py#L1074
 is not accessible anymore.

I think we should replace it by https://tools.ietf.org/html/rfc3875#section-4.1

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Pierre Quentel]

Change by Pierre Quentel :


--
nosy: +quentel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10486] http.server doesn't set all CGI environment variables

[Rémi Lapeyre]

Change by Rémi Lapeyre :


--
nosy: +remi.lapeyre

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34866] CGI DOS vulnerability via long post list

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Matthew Belisle for the nice security counter-measure!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34866] CGI DOS vulnerability via long post list

[Matthew Belisle]

Matthew Belisle  added the comment:

That makes sense Victor, I agree. Thanks for merging those PRs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com