Caddy rewrite based on User-Agent not working

I’m trying to rewrite a path if the requested client is a mobile user. As per caddy documentation, this code should redirect a mobile user to the specified destination.

rewrite /redirect-me {
    if {>User-Agent} has mobile
    to /redirected
}

But it’s wont when I add the User-Agent condition. I tried other condition which works just fine. I tried to look for caddy available directives like User-Agent but can’t find a single hint.

The above example works in testing. Caddyfile:

:2015
rewrite /redirect-me {
  if {>User-Agent} has mobile
  to /redirected
}
log / stdout "{remote} - {user} [{when}] \"{method} {uri} {proto}\" {status} {size} - {rewrite_uri}"

The request:

curl -IL -H "User-Agent:this header has mobile in it" localhost:2015/redirect-me

The log output:

::1 - - [28/Nov/2018:09:40:45 +1000] "HEAD /redirect-me HTTP/1.1" 404 14 - /redirected

The request was successfully rewritten to /redirected. If a file existed there to be served, it would have been.

The rewrite directive does not issue redirects to the client (emphasis mine):

rewrite performs internal URL rewriting. This allows the client to request one resource but actually be served another without an HTTP redirect. Rewrites are invisible to the client.

https://caddyserver.com/docs/rewrite

The redir directive does this.

https://caddyserver.com/docs/redir

Hello,
Thank you very much for your response. Yes in theory it will not redirect and will simply serve the to path content. So technically this code should work:
rewrite /show-me-home {
if {>User-agent} has mobile
to /
}
But it doesn’t and returns 404 :frowning:

I was able to successfully rewrite to the web root index using your code.

Caddyfile
:2015
rewrite /show-me-home {
  if {>User-Agent} has mobile
  to /
}
log / stdout "Originally requested: {uri}, rewritten to: {rewrite_uri}"
Index file
whitestrake at apollo in ~/Projects/test
❯ echo "Test rewrite" > index.txt
Request
whitestrake at apollo in ~
❯ curl -i -H "User-Agent:This header has mobile in it" localhost:2015/show-me-home
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 13
Content-Type: text/plain; charset=utf-8
Etag: "pivylud"
Last-Modified: Wed, 28 Nov 2018 04:17:54 GMT
Server: Caddy
Date: Wed, 28 Nov 2018 04:18:55 GMT

Test rewrite
Log output

Originally requested: /show-me-home, rewritten to: /

Can you please confirm that it doesn’t requires any additional installation? like any extension or something?
Thanks

I can confirm that this requires only the latest version of Caddy, available from the official website, and no third party plugins are necessary.

whitestrake at apollo in ~/Projects/test
❯ caddy -version
Caddy 0.11.1 (non-commercial use only)

whitestrake at apollo in ~/Projects/test
❯ caddy -plugins
Server types:
  http

Caddyfile loaders:
  short
  flag
  default

Other plugins:
  http.basicauth
  http.bind
  http.browse
  http.errors
  http.expvar
  http.ext
  http.fastcgi
  http.gzip
  http.header
  http.index
  http.internal
  http.limits
  http.log
  http.markdown
  http.mime
  http.pprof
  http.proxy
  http.push
  http.redir
  http.request_id
  http.rewrite
  http.root
  http.status
  http.templates
  http.timeouts
  http.websocket
  on
  tls
  tls.storage.file

computefy.com {
gzip
proxy / https://io.computefy.com
rewrite /show-me-home {
if {>User-agent} has mobile
to /
}
}
I’m using this simple config to server the website now, have also reinstalled a fresh server still not working. :frowning:

The website you’ve given seems to be functioning properly.

Note in the requests below that with mobile in the User-Agent header, the following can be observed:

  1. We receive a status 200 from https://computefy.com/show-me-home with content-length: 93177
  2. We receive a status 200 from the web root index of https://io.computefy.com/, the upstream server, with content-length: 93177
  3. We receive a status 404 from https://io.computefy.com/show-me-home, with content-length: 45213; notably, this is the request that would have been made if computefy.com were not successfully rewriting this request prior to proxying

From this, we can infer that https://computefy.com/show-me-home is most likely successfully rewriting the URI to / and then proxying upstream, as configured.

Client request logs
whitestrake at apollo in ~
❯ curl -IL -H "User-Agent:mobile" https://computefy.com/show-me-home
HTTP/2 200
cache-control: no-cache, no-store, max-age=0, must-revalidate
content-type: text/html; charset=utf-8
date: Wed, 28 Nov 2018 06:53:43 GMT
expires: Mon, 01 Jan 1990 00:00:00 GMT
pragma: no-cache
server: Caddy
server: ESF
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block
content-length: 93177

whitestrake at apollo in ~
❯ curl -IL -H "User-Agent:mobile" https://io.computefy.com/
HTTP/2 200
content-type: text/html; charset=utf-8
x-frame-options: DENY
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: Mon, 01 Jan 1990 00:00:00 GMT
date: Wed, 28 Nov 2018 06:53:58 GMT
content-length: 93177
server: ESF
x-xss-protection: 1; mode=block
x-content-type-options: nosniff

whitestrake at apollo in ~
❯ curl -IL -H "User-Agent:mobile" https://io.computefy.com/show-me-home
HTTP/2 404
content-type: text/html; charset=utf-8
x-frame-options: DENY
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: Mon, 01 Jan 1990 00:00:00 GMT
date: Wed, 28 Nov 2018 06:55:03 GMT
content-length: 45213
server: ESF
x-xss-protection: 1; mode=block
x-content-type-options: nosniff

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.