Is there any basic example that shows how to get POST parameters from the request in mod python custom handler. I have no trouble in GET requests, where I get my arguments from request.args, BUT if method is POST, request.args is None.
Thanks.
request.args stores query string parameters, as mentioned in the documentation.
If you want to get POST variables, you can always read the body of the request (request.read()) and parse it (urldecode in your case).
But keep in mind that, as mentioned on the official mod_python homepage:
Current State of Mod_Python
Currently mod_python is not under active development. This does not mean that it is "dead" as some people have claimed. It smiply means that the code and the project are mature enough when very little is required to maintain it.
Which means you may be better off using something more modern, like mod_wsgi.
Related
Ok so I am new to python as a whole. That said I don't know what I'm really looking for to ask this question properly. I know this has to be possible though. I want to ask this before really digging in and finding out I did something wrong and have to do it all over.
All in all what I want to know is, from the front end of my stack I want to pass down custom HTTP headers (which I can do with my Ajax calls, currently). The question is how do I actually read said headers? Similarly how can I pass back up from the server custom headers via python.
You can access custom header in Django view:
request.META.get("Custom_Header")
For django:
How to add an HTTP header to all Django responses
You can definitely do it in the front end. You can do it with Javascript's native XMLHttpRequest, the newer fetch API, jQuery, or some other library (like axios).
I am quite surprised I couldn't find anything on this in my Google searching.
I'm using TwistedWeb to make a simple JSON HTTP API. I'd like to customize the 404 page so it returns something in JSON rather than the default HTML. How might I do this?
There is no API in Twisted Web like something.set404(someResource). A NOT FOUND response is generated as the default when resource traversal reaches a point where the next child does not exist - as indicated by the next IResource.getChildWithDefault call. Depending on how your application is structured, this means you may want to have your own base class implementing IResource which creates your custom NOT FOUND resource for all of its subclasses (or, better, make a wrapper since composition is better than inheritance).
If you read the implementation of twisted.web.resource.Resource.getChild you'll see where the default NOT FOUND behavior comes from and maybe get an idea of how to create your own similar behavior with different content.
I've been deciding between Python web frameworks for a project of mine and I've really liked how lightweight, flexible, and concise CherryPy is compared to others. The only problem I'm having is I can't find any documentation on how to distinguish between data sent via GET and via POST.
For example, I don't want users to be able to provide their login credentials through a GET request (http://example.com/login?username=user&password=pass) but, according to CherryPy's tutorial, all data is sent as method parameters, no matter what HTTP method they're sent as. Is there some way to say I only want the POST data or do I have to use MethodDispatcher?
Thanks!
See the docs.
A string containing the HTTP method, such as "GET" or "POST". Set
in the "run" phase.
looks like checking cherrypy.request.method is what you want to do.
I'm almost afraid to post this question, there has to be an obvious answer I've overlooked, but here I go:
Context: I am creating a blog for educational purposes (want to learn python and web.py). I've decided that my blog have posts, so I've created a Post class. I've also decided that posts can be created, read, updated, or deleted (so CRUD). So in my Post class, I've created methods that respond to POST, GET, PUT, and DELETE HTTP methods). So far so good.
The current problem I'm having is a conceptual one, I know that sending a PUT HTTP message (with an edited Post) to, e.g., /post/52 should update post with id 52 with the body contents of the HTTP message.
What I do not know is how to conceptually correctly serve the (HTML) edit page.
Will doing it like this: /post/52/edit violate the idea of URI, as 'edit' is not a resource, but an action?
On the other side though, could it be considered a resource since all that URI will respond to is a GET method, that will only return an HTML page?
So my ultimate question is this: How do I serve an HTML page intended for user editing in a RESTful manner?
Another RESTful approach is to use the query string for modifiers: /post/52?edit=1
Also, don't get too hung up on the purity of the REST model. If your app doesn't fit neatly into the model, break the rules.
There is no such thing as a RESTful URI. It is false concept as URIs should be completely opaque to the client.
If it helps you to properly implement the HTTP uniform interface by avoiding verbs in your URIs then that's great, but don't feel constrained by what your URI looks like. It is very limiting to think of resource modeling as type of data modelling. A RESTful system usually needs to do way more than just CRUD operations, so you need to be creative about what resources you make available in your system.
If you create a URL and dereferencing it returns a 200 status code, then that URL refers to a resource. If you create another URL and it also returns a 200, then that is a difference resource.
That means:
http://example.org/customer/10.xml
http://example.org/customer/10.json
http://example.org/customer/10?format=xml
http://example.org/customer/10?format=json
are 4 different resources, and
http://example.org/customers
http://example.org/customers?closed=true
http://example.org/customers?page=2&pagelength=20
are also different resources.
Therefore to answer your question, if you do
GET /post/52/edit
and it returns a 200 status code and a representation, then it must be a resource.
Instead of calling it /post/52/edit, what if you called it /post/52/editor?
Now it is a resource. Dilemma averted.
I don't think /object/id/action is part of the REST specification.
Is your editor going to be a generic thing for all objects ? Then maybe your URL should look like
/editor/object/id
The action is an HTTP Verb ( GET,PUT,DELETE,POST ) and is supposed to be a part of the HTTP request and not part of the URL. For a better summary, check out this Wikipedia article on RESTful_web_services.
How can I find out the http request my python cgi received? I need different behaviors for HEAD and GET.
Thanks!
import os
if os.environ['REQUEST_METHOD'] == 'GET':
# blah
Why do you need to distinguish between GET and HEAD?
Normally you shouldn't distinguish and should treat a HEAD request just like a GET. This is because a HEAD request is meant to return the exact same headers as a GET. The only difference is there will be no response content. Just because there is no response content though doesn't mean you no longer have to return a valid Content-Length header, or other headers, which are dependent on the response content.
In mod_wsgi, which various people are pointing you at, it will actually deliberately change the request method from HEAD to GET in certain cases to guard against people who wrongly treat HEAD differently. The specific case where this is done is where an Apache output filter is registered. The reason that it is done in this case is because the output filter may expect to see the response content and from that generate additional response headers. If you were to decide not to bother to generate any response content for a HEAD request, you will deprive the output filter of the content and the headers they add may then not agree with what would be returned from a GET request. The end result of this is that you can stuff up caches and the operation of the browser.
The same can apply equally for CGI scripts behind Apache as output filters can still be added in that case as well. For CGI scripts there is nothing in place though to protect against users being stupid and doing things differently for a HEAD request.
This is not a direct answer to your question. But your question stems from doing things the wrong way.
Do not write Python CGI scripts.
Write a mod_wsgi application. Better still, use a Python web framework. There are dozens. Choose one like Werkzeug.
The WSGI standard (described in PEP 333) makes it much, much easier to find things in the web request.
The mod_wsgi implementation is faster and more secure than a CGI.
A web framework is also simpler than writing your own CGI script or mod_wsgi application.