Forum

I have a question regarding the use of the PUT request.

I currently have a C application that runs as a FastCGI application. The FastCGI configuration in hiawatha.conf is essentially similar to that described in an earlier forum post. It uses URL rewrites.

It is my understanding that Hiawatha does not support the PUT request for URL rewrites. Per the RFC standards:
" If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. " -- from http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6

Now, I would like to use the PUT request with my FastCGI application (called myApp.cgi) to modify an already existing resource - as in # curl --request PUT --data "newState" http://<URL>/state, for instance, with regards to RESTful.

How can I configure Hiawatha in such a way that URL re-writes are turned off and use PUT requests?

With URL re-writes turned off and use of AlterList to allow use of PUT requests with the myApp.cgi, here is the FastCGIServer and VirtualHost configuration.

FastCGIserver {
        FastCGIid = QmyApp
        # 2005 is the FastCGI socket that myApp.cgi uses.
        ConnectTo = 127.0.0.1:2005
        SessionTimeout = 30
        Extension = cgi
}

VirtualHost {
        Hostname = 127.0.0.1
        WebsiteRoot = /home/user/myAppLocation
        StartFile = index.html
        AccessLogfile = /home/user/myAppLocation/logs/access.log
        ErrorLogfile = /home/user/myAppLocation/logs/error.log
        AlterGroup = myAppUsers
        AlterList = allow 127.0.0.1
        AlterMode = 640
        RunOnAlter = /home/user/myAppLocation/myApp.cgi
        UseFastCGI = QmyApp
        ExecuteCGI = yes
}

With URL re-writes turned off, my strategy would be to parse the environment variable REQUEST_URI to obtain the resource to be modified, if the environment variable REQUEST_METHOD has the value "PUT".

However, Hiawatha is not updating the environment variable REQUEST_METHOD, when a PUT request is received. Is there anything I'm doing wrong?

Thanks!

Hiawatha version: 8.8
Operating System: Linux

The PUT request is often misunderstood. A PUT request to a script means that the script should be replaced with the one in the request and not to run the script with the request body as its input. That's what POST is for. Apache got this implemented incorrectly why it's often misunderstood. If you want data to be send to a script, use POST. Only use PUT and DELETE if you want to use the webserver a little like a fileserver.

Thanks for your response, Hugo.

As per the RFC http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6:
" The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server."

Therefore, it is perfectly valid to have the PUT request to modify a resource as per RESTful, not replace the script. Does Hiawatha support this, or is Hiawatha's implementation only targeted at using the PUT request to replace a script?

At this point, Hiawatha replaces the content of a file with the body of a PUT request. Script or no script. Of course, things can be changed, but I have to really think about the consequences. And please note, REST is not an official standard.

Thanks for the quick clarification, Hugo.

If Hiawatha can support the use of the PUT request, as per the official HTTP RFC, to enable modification of an existing resource with reference to a Request-URI - this would broaden Hiawatha's compatibility with the official HTTP RFC.

From http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
"If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request."

I agree that REST is not an official standard, it is only a software architecture style.

Hiawatha does support the PUT request. And it does it according to the official HTTP RFC. This section in the RFC makes it clear that Hiawatha has it right and Apache has it wrong:


Specially the last line is why Hiawatha does not apply URL rewriting to a PUT request.