Mailing List Archive

Altering response based on content-type
Hi.

I'm using Varnish as a cache for a WMS service, and this service will
occasionally time out on a request. If it does it will return either
an image with an error message, or an XML-file with the
error-message. Unfortunately, both responses return the status code
200 OK.

The webclient doesn't handle the XML-response very well, and I don't
want Varnish to cache the images containing error messages.

So - is it possible to get Varnish to return a default image if the
response from the server is an XML-file?

--
Trond Michelsen
Altering response based on content-type [ In reply to ]
In message <20060925075916.GK13253 at crusaders.no>, Trond Michelsen writes:
>Hi.
>
>I'm using Varnish as a cache for a WMS service, and this service will
>occasionally time out on a request. If it does it will return either
>an image with an error message, or an XML-file with the
>error-message. Unfortunately, both responses return the status code
>200 OK.
>
>The webclient doesn't handle the XML-response very well, and I don't
>want Varnish to cache the images containing error messages.
>
>So - is it possible to get Varnish to return a default image if the
>response from the server is an XML-file?

There are no headers we can detect instead ?

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Altering response based on content-type [ In reply to ]
On Mon, Sep 25, 2006 at 08:17:19AM +0000, Poul-Henning Kamp wrote:
> In message <20060925075916.GK13253 at crusaders.no>, Trond Michelsen writes:
>> I'm using Varnish as a cache for a WMS service, and this service will
>> occasionally time out on a request. If it does it will return either
>> an image with an error message, or an XML-file with the
>> error-message. Unfortunately, both responses return the status code
>> 200 OK.
>> The webclient doesn't handle the XML-response very well, and I don't
>> want Varnish to cache the images containing error messages.
>> So - is it possible to get Varnish to return a default image if the
>> response from the server is an XML-file?
> There are no headers we can detect instead ?

If the requests asks for errors to be inline, then no. The response
headers are exactly the same for a successful request as for an
unsuccessful one. In fact the program returns only the bare minimum of
headers. In both a successful and an unsuccsessful request, headers
look like this:

HTTP/1.1 200 OK
Date: Mon, 25 Sep 2006 08:42:46 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) AxKit/1.62 mod_perl/1.29
Transfer-Encoding: chunked
Content-Type: image/png

However, the client can ask for error messages to be returned in one
of three formats:

- application/vnd.ogc.se_xml

In this case, the content-type of the response will be
"application/vnd.ogc.se_xml", so this should be detectable.

- application/vnd.ogc.se_inimage

This will return an image with the error message
embedded. Content-type will be image/png (or whatever format the
client requested).

- application/vnd.ogc.se_blank

This one is actually a bit interesting. I didn't know about it until
right now, and this image will always be of the same size (142 bytes
for PNG), and initial tests indicates that it is different from any of
the blank tiles generated from the mapserver.

So that would give me another option, which probably is simpler. Set
obj.ttl to 0s if its size is 142 bytes. Is that possible?

--
Trond Michelsen
Altering response based on content-type [ In reply to ]
In message <20060925085102.GL13253 at crusaders.no>, Trond Michelsen writes:

>So that would give me another option, which probably is simpler. Set
>obj.ttl to 0s if its size is 142 bytes. Is that possible?

If your backend includes a Content-Length: header you can test on,
yes.

If it uses chunked encoding we won't know the size until after the
vcl_fetch() has been called.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.