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 patch (deleted) — Splinter 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: