![]() ![]() To get the new URL structure applied to all incoming requests I created the following redirect rule, which knows about $language_suffix through this accept language configuration, within a custom NGINX conf file: rewrite ^/$ permanent Besides implementing language redirects for german and english browser languages, we had to create and maintain a lot of outdated page redirects so that we don't miss out on old URL traffic and won't lose any potential customers. This allowed us to be more flexible with any upcoming requests, but it also opened the door for new challenges and pitfalls. In a much longer list, this will matter more.While working on the relaunch of tomorrow.one early last year, we moved the whole web tech stack to Kubernetes and switched to a project based dockerized NGINX setup for our web frontends. This could have been done in one line like the previous one, but part of the point of doing this is to create logical and readable groupings of URLs to ease ongoing maintenance. The fourth and fifth lines make sure that our sign ups and account management pages are always HTTPS. These work like other regular expressions in Nginx which I wont explain here. The tilde character ~ at the start of this line indicates that this is a regular expression. Since Nginx 0.9.6 you can use regular expressions inside maps. The third line is matching our static assets directories which we need to be available over both HTTP and HTTPS. You may want to default to one of the other values depending on which will save you more rules and give you the shortest list. Most of our URLs should always be HTTP, so if none of the patterns in the block match the requested URL, then the result will default to this value of http. The second line is a special default case inside the map. The second variable $example_org_preferred_proto is what we will map the result of the match to. The first variable $uri is what we are checking against in our case the incoming request URL without the protocol, host name or query string. Here’s what a really simple example of that might look like: Rather than build a map of request URIs to redirect locations, we are instead going to build a map of request URIs and their preferred protocols http, https, or none. ![]() ![]() It’s complicated, so just trust me separate maps = do not want! The solution Using one map we can also take advantage of the map default. ![]() There is also potentially a problem with making matches too broad in separate maps and causing redirect loops again, whereas a single map will match only one value. We would need two separate maps and that kind of takes us back to square one. A basic map like that will send our client into a redirect loop. We also only want to redirect to the same URL, albeit over a different protocol. But that is no good for us, because we explicitly want to redirect only if the protocol is not our preferred one. The wiki page on Nginx maps (Nginx HttpMapModule) gives a basic example of using a map to redirect request URLs to new locations. We do this so that when we rebuild sites using Ruby on Rails they don’t loose the Google juice that is already attached to all those horrible, horrible default.aspx?foo=bar&578432754230 URLs… We already use Nginx maps (Nginx HttpMapModule) to create standard redirect lists on some sites, but mostly these are static lists which are used to redirect old URLs to new ones. In cases where the virtual host pulls double duty serving HTTP on port 80 and HTTPS on port 443 simultaneously, we would have to check the protocol first as well, further confusing the config. We also may have to maintain them across two virtual hosts, making it hard to check for conflicts between the two lists. One approach is to use a great big series of rewrite rules, but that would be pretty unwieldy, would involve a bunch of regular expression variable capturing, and likely also mean using more than a couple of if blocks (which I have been told are evil (Nginx wiki - if is evil) and slow, even if few people have the sort of traffic where that really matters). Further, there are some URLs which we want to just stay with whatever protocol they were requested on so they won’t redirect at all. We also need to be able to enforce PLAIN connections (HTTP) on others. We need to be able to enforce SSL connections (HTTPS) on some URLs. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |