Closed Bug 555514 Opened 14 years ago Closed 14 years ago
e10s HTTP: propagate Set
Referrer to chrome process
Right now we DROP_DEAD if you try to call SetReferrer. We should instead set the referrer (both mReferrer and the famously misspelt "Referer" header) on both the tab and chrome process. The easy part of this is to just move nsHttpChannel::SetReferrer into our base class (add a NS_ENSURE_CALLED_BEFORE_ASYNC_OPEN?), then pass mReferrer to SendAsyncOpen. Then we can either 1) just call SetReferrer on the chrome channel with the URI; or 2) do something more efficient. SetReferrer does a lot of fiddling with the URI (stripping off user:pass, etc.) that we will have already done, so ideally we should just set mReferrer directly (by creating a non-IDL public function in nsHttpChannel), and then SetHeader("referer"). We'll want a test, of course (we could add it to test_head.js) Jae-Seong, you want to take this?
This patch is based on Bug 546581. I have a question in HttpChannelParent.cpp, where I am trying to call SetReferrerHeader in nsHttpChannel.h. How do I get nsHttpChannel* inside RecvAsyncOpen?
Use a static_cast--see OnStartRequest for an example. You can cast the nsIChannel you get from NS_NewChannel, or the nsIHttpChannel you QI--any of these can be cast to nsHttpChannel.
Oh, and base your patch off of the patch from bug 546581--that's going to land before this.
Comment on attachment 436144 [details] [diff] [review] patch, 1 Looks great--thanks. nits: Let's change the name of SetReferrerHeader() to SetReferrerInternal(). Get rid of the blank line in the function. Test looks good! Go ahead and update the patch when you get a chance, and I'll check it in once the base channel patch lands
Attachment #436144 - Flags: review?(jduell.mcbugs) → review+
Comment on attachment 436601 [details] [diff] [review] patch, 2 thanks!
Attachment #436601 - Flags: review+
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.