Understanding HTTP PUT

Part of Tutorials

Author(s) and publish date

By:
Published:
Skip to 9 comments

I was in the process of writing an article to explain on how to make possible to edit your Web pages with HTTP PUT and Amaya (W3C technologies testbed authoring tool). The information is scarce on how to configure your server. This is my attempt at explaining HTTP PUT. Your comments are welcome. I'm pretty sure the lazyweb will fix any of my own misunderstandings.

Not many servers handle HTTP PUT in a simple way. There is a good reason behind that. The HTTP specification defines an abstract model for modifying and managing an information space. The "physical action" are unrelated to the use of HTTP verbs. HTTP means create or update a resource. As Roy Fielding put it in 2006:

FWIW, PUT does not mean store. I must have repeated that a million times in webdav and related lists. HTTP defines the intended semantics of the communication – the expectations of each party.

The protocol does not define how either side fulfills those expectations, and it makes damn sure it doesn't prevent a server from having absolute authority over its own resources.

What does it mean for an application which is really Web aware? Let's imagine that you have an information space (Web site), called MyIsland, available at http://MyIsland.example.org/. You are working with a photo manipulation software program. You have set the levels, contrasts, saturation of an image. You resized the photo, which is an object.

You are ready to create a resource to the information space. Let's say that your resource will be identified in the information space by http://MyIsland.example.org/somewhere/coconut. You can now send to the server a request to create the resource in the information space and the image (entity enclosed with the request).

What the server, which is a piece of software, does with the object is not driven by HTTP at all. The server manages the information space (a list of URIs) depending on the requests from clients. The application could store the object on the filesystem, in a database, decompose the image in a series of mathematical equations, to send an email to someone that a new resource has been created, to print it in a real printer, to do a zillion of things additional to the fact that the resource has been created.

It means that later on, if someone does an HTTP GET on this information space at this URI, he/she will receive back the object coming from somewhere. Similarly, the HTTP GET is not a way to say "read this file on the filesystem", but just give me the information designated by this URI. What the server does in the backend is entirely up to the software program. It could be reading a file in the system, it could generate on the fly back the image because it had stored all the equations, a zillion of things.

In the following weeks, I hope I'll get time to give you a bit of code to handle HTTP PUT on your Web server and use Amaya with it. If you have links to online documentation on how to do it practically please leave a comment.

PS: So far I have these:

Related RSS feed

Comments (9)

Comments for this post are closed.