V2: Permanent redirect prompt

When visiting a subdirectory, that’s linked to via a relative path in html
(e.g. <a href="/4g" target="_blank">), by clicking on it, Caddy v2 displays a message like this:

redirect
Is there a way to just direct to the subfolder without Caddy prompting this like Caddy v1 did?

Thank you!

That’s weird. I can’t seem to reproduce that; this link: 4G Throughput Calculator successfully redirects. What does your network log show?

In the meantime, I’ve put up Caddy v1 back again, because I didn’t fully switch to v2, yet. So your result is for v1.
I leave Caddy v2 on for you so please check if you can see what I do see.

Thanks!

Here’s the weird thing, curl -v shows that the server is responding properly:

$ curl -v "https://hnrk.io/4g"
*   Trying 167.86.123.102...
* TCP_NODELAY set
* Connected to hnrk.io (167.86.123.102) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; CN=*.hnrk.io
*  start date: Oct  7 09:57:37 2018 GMT
*  expire date: Oct  7 09:57:37 2020 GMT
*  subjectAltName: host "hnrk.io" matched cert's "hnrk.io"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=AlphaSSL CA - SHA256 - G2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fb7ed806600)
> GET /4g HTTP/2
> Host: hnrk.io
> User-Agent: curl/7.54.0
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 308 
< alt-svc: quic=":443"; ma=2592000; v="1363628031"
< content-type: text/html; charset=utf-8
< location: /4g/
< server: Caddy
< content-length: 40
< date: Fri, 13 Sep 2019 21:27:28 GMT
< 
<a href="/4g/">Permanent Redirect</a>.

* Connection #0 to host hnrk.io left intact

Notice the response status code line: < HTTP/2 308

So caddy is sending HTTP 308 (Permanent Redirect), but both Firefox and Chrome network inspectors show 200.

That’s gotta be a bug in both browsers.

Okay, so I was able to get a 200 back with curl by going to the browsers’ network inspector and copying their request as cURL (right-click the request, click “copy as cURL”) and then running it, shows a 200 response:

$ curl 'https://hnrk.io/4g' -H 'authority: hnrk.io' -H 'pragma: no-cache' -H 'cache-control: no-cache' -H 'upgrade-insecure-requests: 1' -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36' -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3' -H 'sec-fetch-site: none' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9' --compressed -v
*   Trying 167.86.123.102...
* TCP_NODELAY set
* Connected to hnrk.io (167.86.123.102) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; CN=*.hnrk.io
*  start date: Oct  7 09:57:37 2018 GMT
*  expire date: Oct  7 09:57:37 2020 GMT
*  subjectAltName: host "hnrk.io" matched cert's "hnrk.io"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=AlphaSSL CA - SHA256 - G2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f8bbe007600)
> GET /4g HTTP/2
> Host: hnrk.io
> authority: hnrk.io
> pragma: no-cache
> cache-control: no-cache
> upgrade-insecure-requests: 1
> user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
> accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
> sec-fetch-site: none
> accept-encoding: gzip, deflate, br
> accept-language: en-US,en;q=0.9
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200 
< alt-svc: quic=":443"; ma=2592000; v="1363628031"
< content-type: text/html; charset=utf-8
< location: /4g/
< server: Caddy
< content-length: 40
< date: Fri, 13 Sep 2019 21:36:32 GMT
< 
<a href="/4g/">Permanent Redirect</a>.

* Connection #0 to host hnrk.io left intact

So there’s something about the way the browser is making the request that is causing a 200 response :thinking:

Edit: After removing -H 'accept-encoding: gzip, deflate, br' it returns 308 again.

@HNRK I was able to reproduce it with that information, thanks. I pushed a fix to the v2 branch: encode: Fix bug where default status code was being written · caddyserver/caddy@46aaf02 · GitHub

I think something got fumbled up in a rebase a long time ago. Anyway, that should fix this case at least!

1 Like

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