old 18F blog feed URL not redirected

[chuckhoupt]

The old feed URL attempts to redirect to the new feed using an HTML meta-refresh (see feed.md), rather then redirecting to the new URL with an HTTP 301.

Many Feed readers (Safari, NetNewsWire, etc) won't follow a meta-refresh. Only by chance did I notice I hadn't been seeing any 18F posts for the last 6 months! From searching around, I gather a redirect might be setup via the S3/CloudFront console...

Expected Behavior

$ curl -I https://18f.gsa.gov/feed/
HTTP/1.1 301 Moved Permanently
Location: https://18f.gsa.gov/feed.xml
...

Actual Behavior

$ curl -I https://18f.gsa.gov/feed/
HTTP/1.1 200 OK
Content-Type: text/html
...

Steps to reproduce the behavior

• Run curl -I https://18f.gsa.gov/feed/
• Observe 200 result

This is issue is done when:

• Curl command produces 301 and Location header with new URL (https://18f.gsa.gov/feed.xml)

[gemfarmer]

@chuckhoupt thanks for contributing! I'm going to look into enabling a 301 at that url.

[gemfarmer]

Posed question in #federalist-support

[gemfarmer]

We will need to add something like the following to nginx.conf

server {
    listen <%= ENV["PORT"] %>;
    set $target_domain 18f.gsa.gov
    server_name $target_domain;
    rewrite ^/feed/.* $target_domain/feed.xml redirect;
    rewrite ^/([^/]*)$ /$1/ redirect;
  }

cc @jmhooper

[chuckhoupt]

I think it should be a permanent redirect (301) to encourage in-coming linkers to update:

rewrite ^/feed/.* $target_domain/feed.xml permanent;

You might also consider using include files so that the rewrites can be defined in the 18f.gsa.gov repository, rather then elsewhere. Ideally, as a site evolves through multiple re-designs, all accumulated redirects should continue to function -- this is easier to maintain if the redirects are part of the site's repository.

[wslack]

@chuckhoupt how do we put the config in the repo if the config is living in CloudFront? As I read them, those asks seem opposed, since the CloudFront config can't be managed from the repo.

I'm trying to understand the best/simplest implementation. Thank you!

[chuckhoupt]

@wslack My apologies, I don't fully understand 18F's hosting setup, so my suggestions are just "shots in the dark". I'm not certain where 18f.gsa.gov's CloudFront Origin-Server lives: S3 or the Federalist-Redirects VM running Nginx, or elsewhere. Setting up the redirect will depend on the hosting -- maybe a manual S3 change, or maybe a Nginx config change.

[wslack]

@chuckhoupt Sorry about that - that's totally fair. The origin is sitting in S3, so I'm trying to figure out if there's a way to make that work where Jekyll drops a 301 redirect there.

[elainekamlley]

@wslack any update on this issue?

[mgwalker]

With the move over to Federalist, it looks like maybe a tweak to the Federalist redirects in the pages-redirects app might do the trick. I'll chat with the Federalist team to see if that approach makes sense.

[chuckhoupt]

If the site is still hosted on S3, I wonder if redirects couldn't be defined via S3's website configuration bucket? Here's an SO article on how to automate deployment of S3 website.json files:

https://stackoverflow.com/questions/26596337/how-to-update-amazon-s3s-redirection-rules-via-command-line

Note again, I'm an outsider, so this is just another "shot in the dark" idea...

[eddietejeda]

@mgwalker Unfortunately, that's a domain level redirect. We can't use that for specific paths.

@chuckhoupt That's interesting. Hey @amirbey can you check out
https://stackoverflow.com/questions/26596337/how-to-update-amazon-s3s-redirection-rules-via-command-line and see if that's possible with cloud.gov?

[apburnes]

This may now be possible with Federalist's dedicated bucket update. Revisit for customizing redirects.

[apburnes]

Custom redirects are unavailable in Federalist.