My web application has a UI. Some aspects of the UI can be changed (e.g. the language, the theme, the text size). As a concrete example, let's assume that I have a "theme" dropdown box available on every page.

Now, when a user changes the theme, the current page should reload with the new theme, and the new theme should be used for all subsequent page calls. In other words, I want to (a) change some server-side state (the session variable containing the theme name) and (b) reload the page.

I know how to implement this. In fact, I know more than one way to implement this, and this bugs me. I want to find the best way to implement this, and since best is subjective, I want to identify the advantages and drawbacks of both options (and maybe learn about alternative solutions that I didn't even think of).

Here is solution 1:

  • I add the new theme name as a query parameter (i.e. http://example.com/show_orders?customerId=2 becomes http://example.com/show_orders?customerId=2&changeTheme=dark) and reload the page.
  • A generic server-side handler checks for the changeTheme parameter, updates the state and then execution passes on to the specific handler (show_orders), which ignores the unknown changeTheme parameter.

What I don't like about this solution is that

  • page-specific parameters (customerId) and site-specific parameters (changeTheme) are mixed and
  • "state-changing" parameters are in the URL: If the user sends the URL to a colleague directly after changing the theme, calling the URL will also cause the colleague's theme to change. I don't know if there is a specific term for this, but if just "feels wrong" to have a GET request to a resource called show_orders change something. (Feel free to correct me, if my gut feeling is wrong here.)

Here is solution 2:

  • I call a dedicated URL for changing the theme and pass the original page as a parameter, i.e. http://example.com/change_theme?newTheme=dark&redirectTo=%2Fshow_orders%3FcustomerId=2.
  • The change_theme handler changes the session state and then redirects (HTTP 302) to the original URL as defined in the query string parameter.

What I don't like about this solution is that

  • I am redirecting back and forth, which might affect performance, and
  • I am redirecting to a user-supplied value, so I might need to take extra precautions w.r.t. security.

Today, I implemented solution 1 and I am considering to change it to solution 2, for the reasons outlined above. Is this a good idea? Are there pros and cons that I have missed? Is there some superior solution 3, which is well-established best industry practice? If yes, what problems does it solve that options 1 and 2 have?

1 Answer 1


Solution 2 is an well-established practice in the industry, especially when dealing with login screens.

The scenario is then:

  • you navigate to an URL for which authentication is needed
  • the server redirects you to a login page, but also marks the original endpoint either in the URL or in a hidden form field
  • after successful authentication, you are redirected to the page you originally requested.

Also, the pattern POST - redirect - GET is very commonly used when users submit a form to avoid double submissions when the user refreshes the browser page, so the redirect can't have that much of a performance penalty.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.