I am trying to work out the best way to allow content authors to create and manage 301 redirects within the CMS. We are using GSF for friendly URLs, but they also want to be able to (for example) create a catchy URL to be distributed on print media that will redirect to an existing page within the site (or potentially to a page on an external site).
I know that I cannot change the response headers in the JSP, and so am looking at the best way to do so within the existing software stack. The GSTAlias class appears to be almost what I need, but only supports 302 redirects, not 301.
My current though is that I will implement a custom filter (which will compare the incoming URL against the list of redirects that it retrieves from WCS and send a 301 if needed) and insert it into the filter chain, but I was hoping to get some feedback on this and see if anyone had done this before or knew of a better way to do it.
Previously I've done redirects exactly like you, using a custom filter which was installed on the Satellite servers.
My implementation ended being a bit more complicated since all code using friendly URLs had to be executed within a cached code block due to an earlier design decision. What I ended up with was a setup where the templates could generate some output that could be interpretted by the filter. Like #R#301#http://somepage.com# which the filter picked up. Unfortantely that approach required me to read through the output of the pages and add some caching to often requested URLs in order avoid parsing through the content again.
If you have GSF on your site as well, you might have a look at com.fatwire.gst.foundation.httpstatus.HttpResponseStatusFilter which enables you to communicate status codes from the ContentServer. Note that proper redirects are not supported, or at least not implemented.
Also this requires your code to make the decision in a XML based wrapper, since you cannot communicate response codes from JSP.
If the requirements are quite simple, you can create a basic asset type containing the URL to match and where to redirect to and in your XML wrapper do a very simple sql lookup which should give you enough performance in order to have this executed in an un cached element. The SQL cache will save you for the common requested URLs.
Please note, that if you are running remote satellite servers I am not quite sure how this will work, if they support handling other response codes and if they can handle additional information found in a 301 redirect.
Content Authors configure the 301 redirect within the content center by creating / editing the Custom Asset (301 specific) -> On publish, write a jsp to generate xml -> Custom Filter should read the xml either forward the request with 301 status code or delegate to satellite server.
I am also trying to do something around content managed 301s.
Could you please let us know if this approach works with having Remote Satellite Servers as well? I guess we need to then figure out how to transfer the XML file from delivery content Server to RSS servers to work with filter?
We also have a url assembler working on RSS which generate friendly urls, not using GSF framework.
I ended up going with a custom filter that wraps the response in a custom response wrapper, which can then look to see if a redirect is available any time a 404 is encountered. It seems to work pretty well, and I am much more comfortable with low level code like this sitting in a filter rather than in an XML generating template. I am happy to answer any questions anyone might have about it.
Could you please let us know the calling stack right from the time a user hits a url in the browser.
As I understand from the last post,user hits the url in browser which comes to RSS ---> forwards it further to CS ---> once it get back the response, the filter checks if it is 404 ---> check redirects mapping ----> send to redirect url. Is that right?
Are you using Remote Satellite servers ? Is the filter running on RSS? Where does the filter reads redirect mapping from?
We are not running any remote satellite servers, and the filter reads the redirect mapping from the CMS database via the AssetDataManagerImpl. The process is [user requests URL -> request enters the CS -> if CS returns 404 the filter then checks for a redirect -> 404 or redirect returned to user]
I believe that our testing has just uncovered a problem with this approach though, as I think that the 404 response is being cached still and so subsequent requests for that URL are getting the cached 404 page instead of going through the redirect process. If that turns out to be the case then I will have to move to [user requests page -> request enters CS -> check for redirect and return 301 if appropriate -> otherwise process page as per normal] which has some performance implications and so is not ideal.