[TiddlyWeb] - Support HEAD for any GET

[cdent]

At the moment a HEAD request to tiddlyweb will result in a 405, which is not ideal. Things out there in the world do you use head.

One possible solution:

• WSGI app detects REQUEST_METHOD=HEAD, changes it to GET, wraps inner apps
• same app (on the way out), dumps content, but sends headers (keeps the existing start_response)

HEAD (like many things) is controversial in the WSGI world as there's no specific handling of it that works properly in all server setups. Notably Apache can be weird to interact with.

[grahamd]

In what way is Apache weird to interact with? Which WSGI hosting mechanism for Apache are you talking about?

In Apache/mod_wsgi it has specific code for HEAD to ensure that predictable results are obtained when Apache output filters are being used.

/*

• Mutate a HEAD request into a GET request. This is
• required because WSGI specification doesn't lay out
• clearly how WSGI applications should treat a HEAD
• request. Generally authors of WSGI applications or
• frameworks take it that they do not need to return any
• content, but this screws up any Apache output filters
• which need to see all the response content in order to
• correctly set up response headers for a HEAD request such
• that they are the same as a GET request. Thus change a
• HEAD request into a GET request to ensure that request
• content is generated. If using Apache 2.X we can skip
• doing this if we know there is no output filter that
• might change the content and/or headers. */

#if AP_SERVER_MAJORVERSION_NUMBER >= 2

if (r->method_number == M_GET && r->header_only &&

r->output_filters->frec->ftype < AP_FTYPE_PROTOCOL) apr_table_setn(r->subprocess_env, "REQUEST_METHOD", "GET");

#else

if (r->method_number == M_GET && r->header_only)

apr_table_setn(r->subprocess_env, "REQUEST_METHOD", "GET");

#endif

That is, it will turn a HEAD into a GET when it needs to. In the case of Apache 2.X a HEAD can still get through if no Apache output filter, but this is where your application should be handling HEAD in the first place and shouldn't be generating an error.

Anyway, you can most of the safely change HEAD to GET internally to a web application, but you shouldn't necessarily discard any response content as you will not know if some WSGI or web server level output filter needs to see the content to do any header fixups.

[cdent]

Fudged with a bit of WSGI app called Header that does what's described above, including replacing the body iterator with an empty list, despite Graham's excellent info (and excellent mod_wsgi). The common case with TiddlyWeb, at the moment is cherrypy's wsgi server which appears to have no consciousness of HEAD at at all...

Will continue to revisit as necessary.

changeset:9489