The default bug view has changed. See this FAQ.

redirect after a prefetch does not include X-moz: prefetch header

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
Networking
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: Josh Rosenbaum, Assigned: Darin Fisher)

Tracking

({fixed1.8.0.2, fixed1.8.1})

Trunk
mozilla1.9alpha1
x86
Windows XP
fixed1.8.0.2, fixed1.8.1
Points:
---
Bug Flags:
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rft-dl])

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

I'm not entirely sure this is a bug or a design decision, but I could not find any information on this in bugzilla or via google.

I've noticed when surfing Google and it prefetches a site, that it will send the 'X-moz: prefetch' header. However, if the url it fetches is a redirect it does not include this 'X-moz' header when accessing the redirect page.


Reproducible: Always

Steps to Reproduce:
You should be able to just setup a prefetched link in some html that points to a url that redirects to another page. On the second access in the prefetch process you will see that 'X-moz: prefetch' is not included in the header.
Something like:
<link rel="prefetch" href="http://www.xyz.com/">
and let's say http://www.xyz.com/ redirects to: http://www.xyz.com/mypage.html
Actual Results:  
No X-moz header sent for mypage.html.

Expected Results:  
I think the X-moz header might need to be there.
Assignee: nobody → darin
Component: General → Networking
Product: Firefox → Core
QA Contact: general → benc
Version: unspecified → 1.8 Branch
(Assignee)

Updated

11 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.9alpha
Version: 1.8 Branch → Trunk
(Assignee)

Comment 1

11 years ago
Created attachment 209444 [details] [diff] [review]
v1 patch

Simple patch.  I also noticed that nsPrefetchService::mCurrentChannel is not updated when we process a redirect.  I think it should be updated since nsPrefetchService::StopProcessing calls Cancel on mCurrentChannel.
Attachment #209444 - Flags: superreview?(bzbarsky)
Attachment #209444 - Flags: review?(cbiesinger)
Attachment #209444 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 209444 [details] [diff] [review]
v1 patch

+    // HTTP request headers are not automatically forwarded to the new channel.

maybe there should be a way to do that though... but ok, r=biesi
Attachment #209444 - Flags: review?(cbiesinger) → review+
(Assignee)

Comment 3

11 years ago
> maybe there should be a way to do that though... but ok, r=biesi

yeah, this is not the first time we've hit a problem like this.
(Assignee)

Comment 4

11 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Attachment #209444 - Flags: approval1.8.1?
Attachment #209444 - Flags: approval1.8.0.2?
Attachment #209444 - Flags: approval1.8.1? → branch-1.8.1+
(Assignee)

Comment 5

11 years ago
fixed1.8.1
Keywords: fixed1.8.1
Comment on attachment 209444 [details] [diff] [review]
v1 patch

approved for 1.8.0 branch, a=dveditz
Attachment #209444 - Flags: approval1.8.0.2? → approval1.8.0.2+
Flags: blocking1.8.0.2+
(Assignee)

Comment 7

11 years ago
fixed1.8.0.2
Keywords: fixed1.8.0.2
Marking [rft-dl] (ready for testing in Firefox 1.5.0.2 release candidates).  Whoever tests this, please attach the html page with the prefetch link to this bug as a testcase
Whiteboard: [rft-dl]
You need to log in before you can comment on or make changes to this bug.