be more careful when matching HTTP header values

RESOLVED DUPLICATE of bug 325808

Status

()

RESOLVED DUPLICATE of bug 325808
18 years ago
13 years ago

People

(Reporter: darin.moz, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
From brendan's comments on bug 92598:

> Just curious, not picking nits or asking for changes: why PL_strcasestr rather
> than PL_strcasecmp, or perhaps something more complicated that strips leading
> and trailing whitespace (tho I'd hope that PeekHeader does that for you)?  Are
> all the values guaranteed not to be substrings of other legal values?  Can you
> have random garbage around the no-store and get the desired results, according
> to the spec?
> 
> /be

it's possible that future versions of HTTP might define header values which
would "overlap" with existing HTTP/1.1 header values.  it is also likely that 
servers could send us garbage, which could be mistaken for a HTTP/1.1 header value.
I've seen servers send Cache-Control: "no-cache", so we have to be a bit flexible.

I don't have an example url which springs to mind, though.
(Reporter)

Updated

18 years ago
Target Milestone: --- → Future
(Reporter)

Comment 2

13 years ago
-> default owner
Assignee: darin → nobody
QA Contact: benc → networking.http
Target Milestone: Future → ---
fixed by bug 325808 afaict

*** This bug has been marked as a duplicate of 325808 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.