Change Details

**Steps to Reproduce (tentative)** 1) Create a new blog entry at https://phabricator.wikimedia.org/phame/blog/`{id_number}` 2) Browse to the new blog entry via https://techblog.wikimedia.org/`{id_number}` **Actual Results** Blog page is served directly from Phabricator. Blog entry URLs are ugly. **Requested Results** Page is served from Wikimedia CDN cache if possible. Blog URLs are prettier. Brandon suggested that, with the creation of a specific URL (subdomain?) particular to Phame, it would be much easier to cache all of this data and reduce the risk that Phabricator is impaired by heavy traffic to a Phame blog post. We've discussed re-using the old defunct (currently just a redirect) `techblog.wikimedia.org` as the pretty and cacheable entrypoint. There's some configuration work to do on the phame side, as well as DNS and edge cache support. Probably this public-facing URI will not allow authentication at all (readonly), enforced at the cache layer by stripping Authorization/Cookie headers. (This task emerged from a discussion of Phame blogging at the SRE offsite.)

##### Steps to Reproduce (tentative) 1) Create a new blog post via https://phabricator.wikimedia.org/phame/blog/view/15/ 2) Browse to blog via https://techblog.wikimedia.org and view the post. ##### Current Results Blog page is served directly from Phabricator. Blog entry URLs are ugly. Post would currently have urls like https://phabricator.wikimedia.org/phame/live/15/`post/{id_number}/` with the home page at <https://phabricator.wikimedia.org/phame/live/15/>. ##### Requested Results Page is served from Wikimedia CDN cache if possible. Blog URLs are prettier, with a post urls as https://techblog.wikimedia.org/post/`{id_number}/` and the home page at https://techblog.wikimedia.org. ##### Details Brandon suggested that, with the creation of a specific URL (subdomain?) particular to Phame, it would be much easier to cache all of this data and reduce the risk that Phabricator is impaired by heavy traffic to a Phame blog post. We've discussed re-using the old defunct (currently just a redirect) `techblog.wikimedia.org` as the pretty and cacheable entrypoint. There's some configuration work to do on the phame side, as well as DNS and edge cache support. Probably this public-facing URI will not allow authentication at all (readonly), enforced at the cache layer by stripping Authorization/Cookie headers. (This task emerged from a discussion of Phame blogging at the SRE offsite.)

**##### Steps to Reproduce (tentative)** 1) Create a new blog entry atpost via https://phabricator.wikimedia.org/phame/blog/`{id_number}`view/15/ 2) Browse to the new blog entry via https://techblog.wikimedia.org/`{id_number}` **Actualorg and view the post. ##### Current Results** Blog page is served directly from Phabricator. Blog entry URLs are ugly. **Requested Results**Post would currently have urls like https://phabricator.wikimedia.org/phame/live/15/`post/{id_number}/` with the home page at <https://phabricator.wikimedia.org/phame/live/15/>. ##### Requested Results Page is served from Wikimedia CDN cache if possible. Blog URLs are prettier., with a post urls as https://techblog.wikimedia.org/post/`{id_number}/` and the home page at https://techblog.wikimedia.org. ##### Details Brandon suggested that, with the creation of a specific URL (subdomain?) particular to Phame, it would be much easier to cache all of this data and reduce the risk that Phabricator is impaired by heavy traffic to a Phame blog post. We've discussed re-using the old defunct (currently just a redirect) `techblog.wikimedia.org` as the pretty and cacheable entrypoint. There's some configuration work to do on the phame side, as well as DNS and edge cache support. Probably this public-facing URI will not allow authentication at all (readonly), enforced at the cache layer by stripping Authorization/Cookie headers. (This task emerged from a discussion of Phame blogging at the SRE offsite.)