0

I have a Svelte web app exclusively for internal use, so there is no main landing page or registration, as accounts need to be created by the admin. Since the main page has no function as an unauthenticated user, it will redirect to the login page. After a successful login, there is a JS redirect back to the home page, where there will be useful information specific to the account.

Are there any implications to using throw redirect(302, '/login') vs something like if (!user) { document.location = '/login' }? I would guess that the HTTP redirect would be insignificantly faster, but am unsure if there are any side effects from using the temporary 300 codes which the browser would have to handle.

I tried looking up some general rules of thumb for when to use each type, but they usually addressed things like SEO optimization which is a non-concern in this case.

Improve this question
3
  • Are you asking whether it's "better" to "render a page on the server, force the browser create a page structure, parse markup into a DOM, parse and execute JavaScript, and load a whole new page" or "short circuit a request on the server with a tiny HTTP header in an otherwise empty response that any client can quickly recognize and process"? Is one of these options significantly more difficult for you to build? Are there other factors that are causing this to be a non-trivial decision for you?
    – svidgen
    Sep 19 at 14:46
  • @svidgen Either implication is trivially easy. I know browsers will sometimes cache certain pages and use those instead of making a new request to the server and was looking for if that would cause a problem. Also, the HTTP codes usually represent something happening server-side. Not being logged in is definitely a client's problem to deal with, so it seems like it would be a client-side reroute, but like you mentioned it is much more efficient to do it on the server.
    – Jeremy Meadows
    Sep 19 at 14:58
  • 1
    HTTP redirects for auth are pretty common. I'd only favor the fully client-side scripting approach if my framework were heavily client-centric and there were high implementation overhead performing it at page load time. E.g., if my "pages" are all hosted statically from a CDN and my only my API's were dynamic. In that case, it's less trivial to perform an HTTP redirect. Other than that, it's generally much more CPU + network time (and latency) to do all of this on the client.
    – svidgen
    Sep 19 at 16:30

1 Answer 1

Reset to default
1

Using a Javascript redirect can allow you to play a little fast and loose such as deciding half way through rendering a page, that you actually want to force a redirect. NOTE: I am not saying this is a good idea - just that it is possible.

However I would generally choose to use a HTTP redirect instead.

  • It should be fasters (browser doesn't need to render anything to know it has a redirect).
  • It should work for all HTTP requests (not just the main page) - can be useful for REST or images.
  • Usually controls the page history (back button) correctly - this is also possible with JS, but you need to handle that correctly.

There may also be a some peripheral benefits - for example it's easier to say that a HTTP redirect isn't leaking any information - sure you can review the contents of the page to check a JS redirect - but if your going to go as far as making a simple redirect page you may as well just use the proper HTTP redirect mechanism.

Improve this answer

Your Answer

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

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