Change status code for non-url-encoded requests

URLs should be encoded in accordance with RFC3986, yes.

However, some of our incoming requests contain incorrect, non-encoded characters in either the path or query string. Fastly appears to return a 500 status code for these calls. Isn’t this incorrect? Shouldn’t it be a 400 Bad Request?

How can I change this behavior with VCL code?

domain.com/?foo=ö

This doesn’t seem to be testable in Fiddle since the characters appear to be encoded before entering the logic. Or am i doing something wrong?
https://fiddle.fastly.dev/fiddle/5e77bcc1

Hi @strawberry

Thanks for reaching out!

I imagine Fiddle is probably encoding requests before they are proxied through to a test VCL service (as part of the Fiddle architecture).

I myself don’t know what the expected behaviour is for the standard Fastly platform, so I’ve reached out (internally) to our support team to find out.

I’ll provide feedback here once I’ve gotten clarification from them.

Thanks!

A colleague tested this on her own service by making a request to:

curl https://<REDACTED>.global.ssl.fastly.net\?foo\=åäöøæÅÄÖØÆ®ö

They noticed that special characters won’t get encoded in curl but it will get encoded in the browser (see image)

So it could be that some of the clients sending you requests are not encoding the special characters correctly.

Another colleague shared this fiddle which uses urldecode to match the input:
https://fiddle.fastly.dev/fiddle/f4e4095b

It contains the following code…

vcl_recv

if (urldecode(req.url) ~ "[åäöøæÅÄÖØÆ®™]") {
    # Log the request for reference
    log "Request with special characters in URL: " + req.url;

    # Respond with a 400 error
    error 400 "Bad Request";
}

vcl_error

log req.url;
log urldecode(req.url);

This successfully returns a 400.

Thanks,

Yes, this is not testable in Fiddle, but the code snippet works in the actual VCL implementation. Problem solved.

1 Like

Awesome, good to hear. Thanks for the update!