Closed Bug 171102 Opened 22 years ago Closed 22 years ago

prefetch <link rel=prefetch> in addition to <link rel=next>

Categories

(Core :: Networking, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.2beta

People

(Reporter: darin.moz, Assigned: darin.moz)

References

()

Details

(Keywords: topembed, Whiteboard: [prefetch])

Attachments

(1 file)

waldemar pointed out that prefetching more than the first occurance of <link
rel=next> sort of changes the intended meaning of that tag.  rel=next is meant
to point at the next document, but we want to allow content providers to request
the prefetch of, say, some inline images on the next page.  rel=prefetch seems
like a natural choice, and it seems like the HTML standard allows for expansion
of the relational types.

so, this bug is about prefetching <link rel=prefetch> and only prefetching the
first occurance of <link rel=next>.
does this sound reasonable to everyone?  is rel=prefetch a valid extension, or
do i need to define an accompanying "profile" to indicate the meaning of
rel=prefetch.  or, should the relationship be rel=moz-prefetch?  i'm not really
up to speed on what needs to be done to expand on link relationship values.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.2beta
Whiteboard: [prefetch]
use rel=prefetch. 
The spec is open-ended as to what you can put as rel values. I agree with 
waldemar that we need something to fend off overuse of "next" by people who just 
want to prefetch. However, bear in mind that multiple keywords can be present in 
a rel attribute, i.e., <link rel="next chapter">, <link rel="next section">, so I 
think we should continue to prefetch all rel attributes containing the "next" 
keyword.
choess: good point.  okay, i'll keep our rel=next behavior as is, and just add
support for rel=prefetch.  that at least gets rel=prefetch out there, and we can
evangelize that as the preferred prefetch trigger.
Seems reasonable. Technically you do need a profile but in practice nobody knows
what profiles are so don't worry about that.
I think profiles (as in <head profile="...">) are restricted to <meta>, as I
read the spec. (As you point out, it's too vague to really be sure.) I've seen
similar things done within the <link> scope (usually <link rel="schema.foo">
followed by a bunch of <link rel="foo.bar">), but "link types" are explicitly
declared open-ended.

Incidentally, it's probably even less worthwhile than meta-http-link support,
but rel="next" is equivalent to rel="prev" or rel="previous"...
[And thanks, BTW, for your great work on this, darin!]
Attached patch v1 patchSplinter Review
Keywords: patch
(choess means rev= in the last two cases where he said rel=)
the patch seems ok to me except that it doesn't seem to restrict the 1st
occurance of rel=next. should we be liberal and let multiple rel=next trigger
prefetch? Perhaps this is a valid option rather than spending extra
time/effort/code over detecting only the first link rel=next. Either way thanks
for filing and fixing this. r=gagan
Does that patch also fix the XML content sink?
ian: this patch doesn't have any effect on the XML content sink.  i'll get there
sooner or later ;)

gagan: if we encounter rel="next trigger prefetch" we would only prefetch the
specified href once.
Attachment #100969 - Flags: review+
Comment on attachment 100969 [details] [diff] [review]
v1 patch

sr=jst
Attachment #100969 - Flags: superreview+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
fixing summary
Summary: prefetch <link rel=prefetch> and only prefetch the first occurance of <link rel=next> → prefetch <link rel=prefetch> in addition to <link rel=next>
John, I know you're looking at prefetch.  This one is the same topic.  Thanks.
QA Contact: benc → junruh
Verified on Win2000, OSX 10.2.2 and Linux. In-house test URL added above.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: