Last Comment Bug 230703 - Link header parsing is too loose
: Link header parsing is too loose
Status: RESOLVED FIXED
[inbound]
:
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla8
Assigned To: Julian Reschke
:
:
Mentors:
http://www.richinstyle.com/test/attac...
Depends on:
Blocks: 153699
  Show dependency treegraph
 
Reported: 2004-01-12 09:37 PST by Boris Zbarsky [:bz] (still a bit busy)
Modified: 2011-08-05 08:48 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
proposed patch (1.34 KB, patch)
2011-08-03 06:27 PDT, Julian Reschke
bzbarsky: review+
Details | Diff | Splinter Review

Description Boris Zbarsky [:bz] (still a bit busy) 2004-01-12 09:37:03 PST
See also 

http://www.hixie.ch/tests/adhoc/http/link/007.html
http://www.hixie.ch/tests/adhoc/http/link/008.html

Basically, we are parsing things that aren't really Link headers as Link headers.
Comment 1 Julian Reschke 2009-08-02 03:56:39 PDT
Furthermore, it appears that Firefox ignores the "anchor" parameter (see http://tools.ietf.org/html/rfc2068#section-19.6.2.4).

What it should do is resolve the anchor (when given) against the request-uri, and only continue processing it if the resolved URI identifies the same resource.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2009-08-02 20:22:39 PDT
> What it should do is resolve the anchor (when given) against the request-uri,
> and only continue processing it if the resolved URI identifies the same
> resource.

Of course the RFC doesn't actually say any of that.  I'm quite happy to implement what it does say, if I could figure out what that is; it says how the field MAY be used, but not how one MUST process it (or heck, SHOULD or MAY process, for that matter; processing is completely undefined).

In any case, that should probably be a separate bug.
Comment 3 Julian Reschke 2009-08-02 23:52:48 PDT
(In reply to comment #2)
> > What it should do is resolve the anchor (when given) against the request-uri,
> > and only continue processing it if the resolved URI identifies the same
> > resource.
> 
> Of course the RFC doesn't actually say any of that.  I'm quite happy to
> implement what it does say, if I could figure out what that is; it says how the
> field MAY be used, but not how one MUST process it (or heck, SHOULD or MAY
> process, for that matter; processing is completely undefined).
> 
> In any case, that should probably be a separate bug.

1) Just because there's no SHOULD or MUST there doesn't mean it's normative. That being said I agree that RFC 2068 is not very clear about it, and hopefully draft-nottingham-http-link-header can be made clearer.

2) Will open a new bug.
Comment 4 Julian Reschke 2011-07-30 09:07:18 PDT
(In reply to comment #0)
> See also 
> 
> http://www.hixie.ch/tests/adhoc/http/link/007.html

"my" test: 

  http://greenbytes.de/tech/tc/httplink/#simplecssreversed

Opera passes here so I think FF should align. I will work on this.

> http://www.hixie.ch/tests/adhoc/http/link/008.html

I believe this will be fixed once the fix for bug 672079 is in.

> Basically, we are parsing things that aren't really Link headers as Link
> headers.
Comment 5 Julian Reschke 2011-08-01 09:39:17 PDT
> ...
> > http://www.hixie.ch/tests/adhoc/http/link/008.html
> 
> I believe this will be fixed once the fix for bug 672079 is in.
> ...

Is is. (So what's left to fix for this bug are 

  http://www.hixie.ch/tests/adhoc/http/link/007.html

  http://greenbytes.de/tech/tc/httplink/#simplecssreversed
)
Comment 6 Julian Reschke 2011-08-03 06:27:57 PDT
Created attachment 550366 [details] [diff] [review]
proposed patch

This changes the header field parser so that the <target> is only accepted when coming first (this is required by the ABNF and actually enforced in Opera).

This fixes 

 http://greenbytes.de/tech/tc/httplink/#simplecssreversed

and 

  http://www.hixie.ch/tests/adhoc/http/link/007.html

(where http://www.hixie.ch/tests/adhoc/http/link/008.html is already fixed)
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2011-08-03 08:41:46 PDT
Comment on attachment 550366 [details] [diff] [review]
proposed patch

r=me
Comment 8 Marco Bonardo [::mak] 2011-08-05 08:48:09 PDT
http://hg.mozilla.org/mozilla-central/rev/0cff49ed75df

Note You need to log in before you can comment on or make changes to this bug.