Closed Bug 89995 Opened 20 years ago Closed 20 years ago
WRMB: http referrer from https should be supplied when target is same secure server
see bug 82479. We made sure that we would not send the referrer from https to http but the implementation also removed the referrer in the case when the request is to the same encrypted server. This is unnecessary broad.
Priority: -- → P2
Target Milestone: --- → 2.1
*** Bug 89243 has been marked as a duplicate of this bug. ***
ddrinan: you should really use SchemeIs in place of GetScheme/strcmp.
You should be using strcasecmp to compare the schemes and the hosts, since both of those are case insensitive, according to the appropriate RFCs.
adding patch keyword.
r=bbaetz. The spec says (RFC2616, 15.1.3): " Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol." Should we check ports as well, or let it through anyway?
ddrinan, sr=darin provided you fix the indentation to make it consistent with the rest of nsHttpChannel.cpp (4 spaces of indentation).
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer
Fix checked in.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
bbaetz has informed me that this bug is needed for the branch. Re-opening and adding keyword topembed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
this is a war room bug that we'ed like to get on the 0.9.2 branch
Summary: http referrer from https should be supplied when target is same secure server → WRMB: http referrer from https should be supplied when target is same secure server
Approved for check in to the branch by verbal comment from chofmann.
Checked into the 0.9.2 branch. Marking fixed.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Did this re-break in 0.9.3? 0.9.3 on Linux (RH7.1), I'm very clearly not getting the referer (sic referrer) header when going from one https document to a linked https document on the same server.
Just to add a clarification... the problem I'm seeing is https->https, which is technically different than this bug. BUT... this worked properly in 0.9.1, so the patch for this bug may have had the unintended side effect of messing up https->https.
This fix did not make it in to 0.9.3. It's checked into the 0.9.2 branch and the trunk.
*** Bug 93310 has been marked as a duplicate of this bug. ***
*** Bug 97303 has been marked as a duplicate of this bug. ***
*** Bug 100289 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
QA Contact: ckritzer → junruh
*** Bug 103838 has been marked as a duplicate of this bug. ***
*** Bug 96912 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.