Peter Krefting
#Python 3.13 removed the #cgi module, which I am using for a couple of simple documents in an application that I am maintaining. I am happy to rewrite it, especially since I am moving to Nginx that doesn't have CGI support anyway, but to what?
I prefer something that is part of the Python standard libraries (or at least packaged on #Ubuntu). We are using #SCGI (SimpleCGI) for the rest of the application, but the libraries I find for that seem to be quite outdated.
Peter Krefting
@jaseg Thanks! Yes I've found a lot of mentions of wsgi, but wading through search results isn't easy.
What is confusing me when reading up on wsgi, I still need to run the script through the uswgi binary, I cannot just have a stand-alone Python script answer the requests internally and just call a handler function directly?
I should probably try to locate the official uwsgi documentation, the Python library documentation on wsgi was confusing.
jaseg
@nafmo wsgi is pretty much the standard these days. If you just want to handle raw requests yourself, cgi style, you can just use a bare python script with a wsgi runner like uwsgi, which requires no python code beyond a single function definition.
Peter Krefting
@jaseg That was indeed quite minimal. I struggled with the #uwsgi manual and was unable to find a definition for the application interface, but got some help from
https://dev.to/cwprogram/python-deployment-wsgi-with-uwsgi-d45
I have successfully converted the simple scripts, but I have one more complex one that need to handle POST data (both multipart/form-data, possibly some query parameters in the URI, and a direct binary POST with a file upload). The #cgi package did help me there, but I am struggling to find any documentation on how uwsgi handles that.
jaseg
@nafmo uwsgi has a minimal example in their docs. Uwsgi is the thing that runs python, imports your script, and calls a function in it once per request. You only need to provide that function.
Have a look here: https://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.html
Jonathan Hartley
@nafmo @jaseg off the cuff idea, if you can't navigate the docs, then start sending POST requests with the body or data attached, and introspect the resulting requests as they arrive in your code. Eg. print(vars(request)) , (if a 'request' object is what uwsgi uses, all the frameworks blend into one for me...)
Peter Krefting
@tartley @jaseg Yeah, that's basically what I end up doing when docs (or my skills at navigating them) are lacking...
I've found a few pointers on parsing POSTs in uwsgi, but they are all old (pre-2010) and suggesting the use of the very cgi module that has now been removed from Python...
Jonathan Hartley
@nafmo @jaseg oooh, this should be extremely do-able. If nobody else responds I'll try and come back to this after breakfast/school run...
Peter Krefting
@tartley @jaseg The email module might work, it seems to be able to do some of the things I need.
I'm trying to avoid having too many dependencies that I need to install, that's why I am trying to do this with the minimal set of modules, preferrably doing as much as possible with the standard Python libraries.
If all else fail, I could probably rewrite it into C++ or golang, I have some frameworks available there already for the other parts of the application, but that's a much bigger job.
Peter Krefting
@tartley We ($DAYJOB) deliver a software package on both embedded and server platforms. We have been using Nginx on the embedded for several years, but were running Apache on RHEL platforms before switching over to Nginx on Ubuntu, mainly to make them as similar as possible, to ease maintenance.
The server platform has two products that can be installed side-by-side, and some of the common parts (routing default URLs to the correct product) was a simple CGI script doing a redirect. That's what I am rewriting, since Nginx doesn't do CGIs.
It's proprietary software, but the CGI scripts are of course readable, being scripts. I'll add links to the packages in a comment to this.
Jonathan Hartley
@nafmo You mention moving to nginx. Is this because you expect a lot of requests, or some other reason?
Jonathan Hartley
@nafmo Let me re-read your thread. I suspect there's something I'm missing out on.
Jonathan Hartley
@nafmo Hey, I'm back at my desk. I'm going to ask dumb questions to make sure I understand. Are you able to share any links to what you currently have? Either the existing CGI code, or your newfangled wsgi experiments?
One thing: uwsgi is one of the more powerful and flexible Python app servers (e.g. it is actually a multi-language framework, also supporting Lua, PHP, etc). This makes it complicated. My knee-jerk would be to start with something simpler like gunicorn.
Peter Krefting
@tartley Common parts: https://repo.bridgetech.tv/btech/dists/noble/vbc-6.5/binary-amd64/btech-ssg_4.1.0_amd64.deb - installs some .cgi files that are very simple, they converted just fine (those versions are not available anywhere yet)
https://repo.bridgetech.tv/btech/dists/noble/vbc-6.5/binary-amd64/btech-vbc_6.5.0.1_amd64.deb - here I am looking to convert the slightly over-engineered "snapshot_upload" script. It has some shenanigans going on combining POST and GET, and confusing POST with PUT.
Peter Krefting
Since I have a single script using the #Python #cgi module (the rest is C++ using SimpleCGI), I figured that switching to a full framework was overkill. So instead I am rewriting using urllib.parse.parse_qs for the query string and email.parser for the multipart body.
Thanks for all the helpful comments! I found #uwsgi to be very useful for other parts of the code.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.