Can we fetch some resources from a specific URL?

Comments

3 comments

  • Justin

    You can make requests from servers that you have explicitly declared in your configuration beforehand. In other words, what you request can be dynamic, but not from where.

    If a request comes in for /something you can send the request to help fulfil it to any one of your pre-configured backend hosts, but it doesn't have to be for the same path. In VCL you can make the request be sent to my-origin-server1.example.com/something-else or my-origin-server2.example.com/something-different. As long as you were careful not to stomp on the cache key (so you didn't end up storing different things for the same request, which would also make purging difficult) it'd be OK.

    And that takes me to a related subject: if you are really making dynamic choices as to what to serve a user based on something, and different responses could be cached for the same cache key (usually Host header + path/query string) you should be using the Vary header to signal to the cache that a particular header should also be taken into account when storing content for that Host/path combination. See here for more on this.

    So, if I'm understanding you correctly, the answer is 'yes', but I'd add 'be careful!'.

    0
    Comment actions Permalink
  • Andrew Betts

    Iff you want to make routing decisions (ie. which backend to send to, or what URL to rewrite the request to), based on dynamically changing information, there are a few ideas you can try:

    1. Check out our dynamic Edge dictionaries feature. This provides a simple key-value dictionary that you can update via the API and access through your VCL. So you could, for example, maintain a list of redirects mapping source URL to destination URL in a dictionary and then write generic redirection logic in VCL (https://fiddle.fastlydemo.net/fiddle/bb769ce6)

    2. There's a variety of information available in VCL itself, such as geoip data. You can read that data and make routing decisions based on that (https://fiddle.fastlydemo.net/fiddle/e43b44e0)

    3. For more complex decisions, such as access control or A/B testing, you might want to use what we call the preflight pattern. This means making a request to one backend, taking some data from the response and using it to decide what to request from a second backend, then making a second request and returning the second response to the end user. https://fiddle.fastlydemo.net/fiddle/f1bbff1e

    With these examples I've included links to a new experimental tool we've been working on, which allows you to play around with Fastly service configuration without having a Fastly account. This is a very early preview so we don't have detailed documentation for the tool, but if you find it useful you're welcome to use it, and we'd love feedback.

    0
    Comment actions Permalink
  • Christopher Hogan

    For what it's worth, we've successfully used something similar to the preflight pattern @triblondon called out, and done so in such a way that the preflight result is cached.

    The big catch is this does not work for requests that have bodies. If a request has a body, then the client streams the body during the first "preflight" request, so when the second (original) request is made, it has an empty body (and a now-incorrect Content-Length).

    As far as I know, this a behavior of Varnish that is not easily changed.

    0
    Comment actions Permalink

Please sign in to leave a comment.