Last modified: 2014-05-19 04:48:51 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T62488, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 60488 - Redirect loop accessing the non-SSL root URL for logstash.wikimedia.org
Redirect loop accessing the non-SSL root URL for logstash.wikimedia.org
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Logstash (Other open bugs)
wmf-deployment
All All
: Unprioritized normal (vote)
: ---
Assigned To: Faidon Liambotis
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-27 19:11 UTC by Bryan Davis
Modified: 2014-05-19 04:48 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Bryan Davis 2014-01-27 19:11:25 UTC
Several users have reported seeing a redirect loop error page when attempting to access http://logstash.wikimedia.org. Using the https protocol seems to correct the issue.

I have personally not been able to recreate the redirect loop in my browser, but I can recreate it using curl from the command line:

    curl -v -L http://logstash.wikimedia.org

Expected:
* GET / HTTP/1.1
* 301 Moved Permanently; Location: https://logstash.wikimedia.org/
* GET / HTTP/1.1
* 401 Authorization Required

Got:
* GET / HTTP/1.1
* 301 Moved Permanently; Location: https://logstash.wikimedia.org/
* GET / HTTP/1.1
* 301 Moved Permanently; Location: https://logstash.wikimedia.org/
* ...


Behavior seems to be intermittent. During testing to file this bug I could recreate the looping behavior for several requests in a row followed by several proper redirects followed again by several redirect loops. This seems to indicate that a single node in a load balanced cluster is misbehaving.
Comment 1 Bryan Davis 2014-01-27 19:18:05 UTC
Ori suggested assigning to Faidon for triage/resolution.
Comment 2 Bryan Davis 2014-01-27 21:17:44 UTC
It looks like Varnish is caching the 301 response under some circumstances:

    < HTTP/1.1 301 Moved Permanently
    < Server: nginx/1.1.19
    < Date: Mon, 27 Jan 2014 21:12:13 GMT
    < Content-Type: text/html; charset=iso-8859-1
    < Transfer-Encoding: chunked
    < Connection: keep-alive
    < Location: https://logstash.wikimedia.org/
    < Vary: Accept-Encoding
    < X-Varnish: 2005611465 2005610948
    < Age: 102
    < Via: 1.1 varnish
    < X-Cache: cp1044 hit (450)

Maybe a cache-control header needs to be added when sending the 301 to switch protocols?
Comment 3 Bryan Davis 2014-01-28 18:43:08 UTC
I think there are two possible solutions to this:

1. Send a Cache-Control header along with the 301 response to keep Varnish from caching the redirect
2. Add the X-Forwarded-Proto header to the hash inside Varnish

    sub vcl_hash {
      if (req.http.X-Forwarded-Proto) {
        set req.hash += req.http.X-Forwarded-Proto;
      }
    }
Comment 4 Aaron Schulz 2014-01-28 18:57:28 UTC
Can X-Forwarded-Proto by used with a Vary header?
Comment 5 Aaron Schulz 2014-01-28 18:57:41 UTC
(In reply to comment #4)
> Can X-Forwarded-Proto by used with a Vary header?

*be used
Comment 6 Gerrit Notification Bot 2014-01-30 16:55:58 UTC
Change 110393 had a related patch set uploaded by BryanDavis:
varnish: Add X-Forwarded-Proto to Vary on redirects

https://gerrit.wikimedia.org/r/110393
Comment 7 Gerrit Notification Bot 2014-01-30 17:36:23 UTC
Change 110396 had a related patch set uploaded by Ori.livneh:
kibana: Set Vary: X-Forwarded-Proto on HTTP -> HTTPS 301s

https://gerrit.wikimedia.org/r/110396
Comment 8 Gerrit Notification Bot 2014-01-30 17:36:52 UTC
Change 110396 merged by Ori.livneh:
kibana: Set Vary: X-Forwarded-Proto on HTTP -> HTTPS 301s

https://gerrit.wikimedia.org/r/110396
Comment 9 Gerrit Notification Bot 2014-01-30 17:37:03 UTC
Change 110393 abandoned by BryanDavis:
varnish: Add X-Forwarded-Proto to Vary on redirects

Reason:
Ori's workaround in Id2cc29f911fa36805320cdb606a5da1226c9d230 is less yucky

https://gerrit.wikimedia.org/r/110393
Comment 10 Bryan Davis 2014-01-30 17:47:26 UTC
Ori fixed this with a cool bit of Apache config:

  RewriteRule ^/(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,E=ProtoRedirect]
  Header always merge Vary X-Forwarded-Proto env=ProtoRedirect

This works around an annoying bit of esoteric Apache internals where headers are stripped during redirect generation and have to be reapplied later. See http://stackoverflow.com/a/3711110/8171 for a description of the underlying "feature" that is being addressed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links