REST resource 404 response?

(Nathan Irwin) #1

Can I force a non-200 response from a REST resources’ js code?

We use js rest resources for accessing certain content. eg GET content=fruits

I want to be able to 404 the pages asking for missing content or making otherwise invalid requests eg content=potato-fruits

It’s trivial to render “not found” text, but I want to be able to modify the http response status header of the page, so machines such as caches do not cache “not found” texts because the server response was 200 but the content was missing.

Change response code in header from a design asset
(Bart Banda) #2

Not from a REST asset itself, but if you are on version 5.3.5.0 or above, you could maybe use the Send HTTP Header to overwrite that somehow?

https://matrix.squiz.net/manuals/triggers/chapters/trigger-actions#send-http-header

(Marcus Fong) #3

One important thing to note here is that 404 responses are not necessarily uncacheable. Just as with 200 responses, it depends on the value of the Cache-Control HTTP header.

(Nathan Irwin) #4

Thanks both. Look like setting a http header with this trigger could work, but we’re aren’t currently on that version. Are there any other ways to set http headers with REST assets or something else that a RESST asset could use?

(Marcus Fong) #5

Checking back with RFC7230 which defines modern HTTP/1.1, I don’t think Send HTTP Header can be used to overwrite the response status - Section 3, “Message Format” makes it clear that the response code is part of the “Start-Line” and is not one of the “header-fields” which come afterward.

One thing I would also ask is: why is it considered undesirable to cache the “not found” replies for missing content? Is it likely that the missing content will be added in the period before the cache expires?

(Nathan Irwin) #6

Thanks, the RFC makes sense.

Its undesirable to cache bad responses over a previously good response for the same query or url, a 404 status triggers the stale-if-error timeout and the good response continues to be delivered to or reused by a client.

(Marcus Fong) #7

So the 404 in your case actually represents some kind of transient error condition?

Do you have some kind of custom stale-if-error setup on your reverse proxy for that to happen? RFC 5681, which defines the stale-if-error Cache-Control extension, states that:

In this context, an error is any situation that would result in a 500, 502, 503, or 504 HTTP response status code being returned.

(Nathan Irwin) #8

Correct, though Im likely going to have to set a custom header with the Send HTTP Header feature and re-write my custom stale-if-error to work with that header.

Unless there is another way to do this without the Send HTTP Header feature, as my Matrix version doesn’t have this feature.

VCL 
 /* handle 5XX (or any other unwanted status code) */
if (beresp.status >= 500 && beresp.status < 600 || beresp.newErrorHeader) {

/* deliver stale if the object is available */
if (stale.exists) {
  return(deliver_stale);
}
(Marcus Fong) #9

Oh, you’re using Varnish. In that case, couldn’t you just set resp.status to 404 using the same conditional as your stale-if-error?

As regards that conditional, if you really can’t arrange a Matrix upgrade and are feeling particularly adventurous, there’s a Varnish VMOD that allows you to match against a string in the response body (note that I can’t say how well it works, as I’ve never used it):

(Nathan Irwin) #10

Only if I have a response header to say something within the REST asset response is busted, hence changing the HTTP response or using Send HTTP Header feature - I need Matrix to indicate somethings up before it gets to the cache, otherwise all Matrix responses look the same to cache - good or bad.

Planning on Matrix upgrade as soon as 5.5 is out, which is due Q1 apparently.

(Marcus Fong) #11

Yes, that was why I mentioned the bodyaccess VMOD - but it looks like I misread its documentation. libvmod-bodyaccess currently only allows access to the request body in VCL.

You can’t do it in Nginx either, since the response body is only processed after the response headers are sent. So it seems like the Matrix upgrade is the only option.