AutoComplete Forces HTTP
I set up my tracks instance to be proxied by Apache (similar to a few apps I have) at https://www.myhost.com/gtd. Going to http://www.myhost.com/gtd will 302 redirect you to https. This works perfectly for essentially everything. The only thing that doesn't work is autocomplete, which still uses http. As a result, I get a "There was an error retrieving from server: error" in the upper right hand corner, and every time it prompts me with "New context '@Work' will also be created. Are you sure?"
I verified via a wire capture that when I try to create a todo, it OPTIONS to /gtd/contexts.autocomplete?_source_view=project&term=@work. The server responds with the 302 redirect, and the connection terminates, without any https traffic at all.
Is this an easy fix, that I could perhaps patch in my own environment? I will only ever use https, so I could switch completely to that, if it's hardcoded somewhere.
I verified via a wire capture that when I try to create a todo, it OPTIONS to /gtd/contexts.autocomplete?_source_view=project&term=@work. The server responds with the 302 redirect, and the connection terminates, without any https traffic at all.
Is this an easy fix, that I could perhaps patch in my own environment? I will only ever use https, so I could switch completely to that, if it's hardcoded somewhere.
Leave a comment
ajax call should follow 302. I see a bug in firefox where request headers are not reused (https://bugzilla.mozilla.org/show_bug.cgi?id=553888)
could you check if your setup does work using another webbrowser?
In your report you mention autocomplete but also adding new todos. Are all ajax calls failing? or just the autocomplete?
could you check if your setup does work using another webbrowser?
In your report you mention autocomplete but also adding new todos. Are all ajax calls failing? or just the autocomplete?
on 2011-06-08 05:23 *
By lrbalt
Status changed from New to Invalid
Status changed from New to Invalid
hm, I think the problem starts here in Tracks: https://github.com/bsag/tracks/blob/master/app/views/layouts/standard.html.erb#L24
root_url returns, in your setup, http://myhost.com/gtd, not with https. You can check this by looking at the html source of your tracks page on line 28. This is because Tracks (rails) does not know that you are using SSL, but Rails is able to read the header X-Forwarded-Proto. I found you can add
RequestHeader set X-Forwarded-Proto "https"
in your apache config to forward https to rails and Tracks should pick this up automagically. You can test using the source in your browser where http should be changed into https
Closing as invalid as this is an issue in your config
root_url returns, in your setup, http://myhost.com/gtd, not with https. You can check this by looking at the html source of your tracks page on line 28. This is because Tracks (rails) does not know that you are using SSL, but Rails is able to read the header X-Forwarded-Proto. I found you can add
RequestHeader set X-Forwarded-Proto "https"
in your apache config to forward https to rails and Tracks should pick this up automagically. You can test using the source in your browser where http should be changed into https
Closing as invalid as this is an issue in your config