#2597 closed defect (bug) (fixed)
304 Not Modified Headers not returned in RSS2 feed
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 2.0.7 | Priority: | normal |
Severity: | major | Version: | 2.0.2 |
Component: | Administration | Keywords: | 304 http headers feed RSS2 |
Focuses: | Cc: |
Description
Scott Sanders of FeedLounge noticed that IJSM.org's RSS2 feed was not 304-aware. IJSM.org is running WPv2.0.2. That sent me on a goose-chase around my box, knowing that I have WP installs at a variety of revision levels [bad, I know].
v2.0 RSS2 feed shows up as returning 304.
v2.0.1 RSS2 feed shows up as returning 304.
WordPress.com RSS2 feed shows up as returning 304.
v2.0.2 RSS2 feed does not return a 304.
I have checked the /rss/, /comment/, and /atom/ feeds for IJSM.org and they also show no 304 headers returned.
The comments feed for the 2.0.1 install I have returns a 304 as it should.
I don't know if this is related to the security fixes of 2.0.1--->2.0.2; if so, I'm okay with it. I'll take the bandwidth hit on my box over the probability of my box being 0WN3d. That said, this is still an issue.
I'll leave those feeds untouched through until Sunday evening Central time so that there's time to check them. Past then, I need to secure my box.
Thanks for your time!
Attachments (1)
Change History (12)
#1
@
19 years ago
I made a typo with the comments feed in the third paragraph. Please accept my apologies. The appropriate feed to test: http://ijsm.org/comments/feed/rss2/
#2
@
19 years ago
Emil Sit may have found the culprit, which seems to relate to either changeset:2699 or changeset:3572. The quick fix seems to be to add an extra stripslashes call on line 248 of classes.php.
#3
@
19 years ago
It would probably be better to find a real fix; I think the intention is that $_SERVER is quoted once, either by PHP's magic_quote or by some calls to addslashes in WP. The problem is (I believe) that both are happening on some configurations/versions of PHP: PHP magic_quote's server, and then WP calls addslashes (and then at some point calls stripslashes).
Of course it is safe in this usage to stripslashes since the check that the ETags are the same is just a string comparison (not some SQL statement, e.g.) but I could imagine that there may be some potential deeper problems and this is only one possible manifestation.
#4
@
19 years ago
I wonder if some php versions are magic quoting $_SERVER and others are not. We had a security bug where we were assuming $_SERVER was quoted by magic quotes when in fact it wasn't. That led to the current code where we assume $_SERVER is never quoted by magic quotes.
#5
@
19 years ago
All my testing indicates that $_SERVER
is, in fact, quoted by magic_quotes_gpc
There are a limited number of HTTP headers you can inject quotes into just by using a browser, so I opened up a telnet session and injected quotes everywhere that I could (without invalidating the HOST, for example) and found that all these places were slashed when magic_quotes_gpc
was on.
I'm running PHP 4.3.10-16
The PHP documentation on this is wrong, or at best, incomplete.
Was the alleged vulnerability with $_SERVER ever tested? I don't see a ticket associated with the commit. It could have just been submitted to security@…
#7
@
18 years ago
- Milestone changed from 2.1 to 2.0.7
- Resolution fixed deleted
- Status changed from closed to reopened
Needs fixing for 2.0.x
A minority is affected, but it's a pretty big deal for those folks.
#10
@
12 years ago
In [23573], I've removed this second strip.
I don't know exact timelines or history, but long before PHP 5.2, magic_quotes_gpc stopped affecting $_SERVER. We have never stripped $_SERVER when magic_quotes_gpc was on, and only added unconditionally. This resulted in double slashes.
Now that magic_quotes_gpc never affects $_SERVER, we always end up with exactly one level of slashing.
Thus, [3682] can go.
#11
@
12 years ago
As found by Jon Cave, https://github.com/php/php-src/commit/0f3a0dfa52983db76df9149f75bc63608efd4d57. PHP 5.0, $_SERVER magic quoting was removed.
HTTP headers for each case outlined in Ticket 2597.