/app redirects not working correctly

Runbox 7 Runbox 7 Webmail
#1

When typing “runbox.com/app” into my browser, the request fails to load. Seems that two redirects are in place, but not chaining together properly.

  1. Type “runbox.com/app”
  2. This redirects to: http://runbox.com/app/, but then dies
  3. Refreshing the above #2, then correctly redirects to: https://runbox.com/app/

Redirect instructions are very simple to set up correctly, especially on Nginx, so you may want to review that to avoid unnecessary failed requests.

Instead of two redirects, just go straight to the ideal destination, and make sure they are permanent redirects.

http://runbox.com/app --> https://runbox.com/app/
https://runbox.com/app --> https://runbox.com/app/

  • In all of the above, take note of the http:// vs https://, and the differences in trailing slashes.
#2

Hi,

Thanks for this. I am not seeing a problem just entering runbox.com/app in any of my browsers here. It correctly redirects to https://runbox.com/app/

What is your exact set up please so we can try to replicate this?

#3

I’m not seeing this either, in Firefox and Opera on OS X.

  • Geir
#4

Seeing the same, redirect not working.
Palemoon 27.9.3 on latest Antix linux (17)

Noscript and requestpolicy addons are installed, but Runbox is allowed.

Firefox ESR 52.9.0 (64-bit) on the same laptop redirects fine.

#5

Same on Devuan ascii, with updated Palemoon 27,9,4, also with noscriptand requestpolicy installed, but runbox allowed.
Firefox ESR 52.9.0 (64-bit) again works fine. No extra addons installed at all.
Maybe I should uninstall the addons in Palemoon just to have tested. Even if runbox is allowed.
Palemoon does not support noscript anymore …

#6

Just an update on this issue. Still not fixed.

(Forum is trying to embed the video, but it doesn’t seem to be playing. Here is the link. Just remove the spaces… https:// www. dropbox. com/s/dh2kcj3n13zgvqd/Runbox-app-redirects.mov?dl=0

#7

Hi,

Thanks for the demo video. I’ve just tried this in Safari in a new private window and I get the same result as you.

However, doing the same in Opera the page redirects to runbox.com/app/, and in Firefox it redirects to Runbox 7 Chrome also behaves the same as Firefox. So it would seem to be Safari specific out of the ones I’ve tried.

#8

Okay, fair enough. So the affected browsers are limited.

Safari is my primary browser, and I develop and maintain over 30 websites across a dozen servers. All of them have such redirects in place — (a) adding trailing slashes, and (b) switching to a secure URL… and none of them ever fail with this same error. I added the redirect instructions myself, so I’m well-versed with this stuff.

I appreciate you watching the video. But I’m curious if you plan to review the configuration so that this issue can be addressed?

Note, Mobile Safari is also affected, so this will potentially affect quite a few people if left in place.

1 Like
#9

A bit of research. Seems that if a “Content-Length” header is sent with a value of zero (0), then Safari dies instead of following the Redirect.

Here are the headers from four separate servers. They all give slightly different results, but the only difference with Runbox is the presence of Content-Length header and no Content-Type header.

==== runbox.com/app ====

HTTP/1.1 301 Moved Permanently
Content-length: 0
Location: https://runbox.com/app
Connection: close

==== apple.com =====

HTTP/1.1 301 MOVED PERMANENTLY
Server: Apache 
Date: Thu, 13 Sep 2018 00:36:34 GMT
Location: https://www.apple.com/
Content-type: text/html
Connection: close

====== google.com =======

HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Thu, 13 Sep 2018 00:37:28 GMT
Expires: Sat, 13 Oct 2018 00:37:28 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

====== filcan.store (one of my sites) ======

HTTP/1.1 301 Moved Permanently
Server: nginx/1.14.0
Date: Thu, 13 Sep 2018 00:35:34 GMT
Content-Type: text/html
Content-Length: 185
Connection: keep-alive
Location: http://www.filcan.store/

================================

If suspect if you remove the Content-Length: 0 header on these redirect-only responses, the problem may go away.

1 Like
#10

Yes, I am sure that now we know how to reproduce the problem it will be looked in to.

Thanks for the further detail, it is useful and much appreciated :slight_smile:

1 Like
#11

It seems that the redirect issue has been fully resolved now. Thanks.