HTTP - Revision history

MikeSmith: Add HTTP 0.9 (and Legacy Shoutcast support)

2017-01-21T12:45:04Z

Add HTTP 0.9 (and Legacy Shoutcast support)

← Older revision		Revision as of 12:45, 21 January 2017
Line 87:		Line 87:
	http://www.ietf.org/mail-archive/web/http-state/current/msg01447.html		http://www.ietf.org/mail-archive/web/http-state/current/msg01447.html

			== HTTP 0.9 (and Legacy Shoutcast support) ==

			See https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/qS63pYso4P0/7_cMXoKXAwAJ

	[[Category:Spec_coordination]]		[[Category:Spec_coordination]]

Annevk at 11:56, 21 November 2014

2014-11-21T11:56:25Z

← Older revision		Revision as of 11:56, 21 November 2014
Line 82:		Line 82:
	mnot: That'll happen when RFC723x go to full Standard.		mnot: That'll happen when RFC723x go to full Standard.


			== Assume Vary: Cookie ==

			http://www.ietf.org/mail-archive/web/http-state/current/msg01447.html


	[[Category:Spec_coordination]]		[[Category:Spec_coordination]]

Annevk: /* [Not an issue] Assume Vary: User-Agent */ remove this non-issue

2014-08-04T18:29:07Z

[Not an issue] Assume Vary: User-Agent: remove this non-issue

← Older revision		Revision as of 18:29, 4 August 2014
Line 83:		Line 83:


	~~== [Not an issue] Assume Vary: User-Agent ==~~

	UAs and intermediary caches should act as if all responses had Vary: User-Agent specified since many pages on the Web serve different content depending on the User-Agent header but do not bother specifying Vary: User-Agent.

	~~'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0114.html~~

	:You may as well not have a cache if you do this. It's hard to find two users with the same User-Agent string if you try. It varies based on minor browser version, major OS version, and in old IE doesn't it vary based on installed plugins? Yes, some pages will break if you run a transparent caching proxy and don't vary based on UA, but it will be a small minority and somewhat random, and generally they'll fix themselves if you force-refresh. (Browsers send Cache-Control: no-cache when you force-refresh, which will skip a normally-configured cache.) Even if you vary based on UA, caching proxies will break some pages, because some sites serve incorrect caching headers and a caching proxy will make you hit these more often even in the single-user case. (E.g., hitting refresh will skip browser cache for the current page but not proxy cache, right?)<p>So basically, this is a performance vs. correctness tradeoff, and the correct answer for the vast majority of users is not to have a caching proxy at all. Some will want a caching proxy that serves them some incorrect pages. No one wants a caching proxy that varies based on UA, because then the cache will be useless. The only case I could think of where this might make sense is in an office with a homogeneous browser environment, which wants caching for its standard browsers (which all have the same UA string), but still wants to be relatively correct for people using Wi-Fi on their laptops with different browsers. But it's not something that makes any sense to require across the board. [[User:Aryeh Gregor\|Aryeh Gregor]] 08:45, 17 October 2012 (UTC)

	~~mnot: Yeah, that's a really bad idea.~~

	[[Category:Spec_coordination]]		[[Category:Spec_coordination]]

Annevk at 18:26, 4 August 2014

2014-08-04T18:26:41Z

← Older revision		Revision as of 18:26, 4 August 2014
Line 1:		Line 1:
	This page is an attempt to document some discrepancies between browsers and RFC 2068 (and its successor, RFC 2616) because the HTTP WG seems unwilling to resolve those issues. Hopefully one day someone writes HTTP5 and takes this into account.		This page is an attempt to document some discrepancies between browsers and RFC 2068 (and its successor, RFC 2616) because the HTTP WG seems unwilling to resolve those issues. Hopefully one day someone writes HTTP5 and takes this into account.

			== Header parsing: newlines ==

			http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0123.html

			== Header parsing: handling "duplicates" ==

			https://bugzilla.mozilla.org/show_bug.cgi?id=376756

	== Content-Encoding ==		== Content-Encoding ==

Jakearchibald at 14:59, 15 July 2014

2014-07-15T14:59:31Z

← Older revision		Revision as of 14:59, 15 July 2014
Line 8:		Line 8:
	Not raised. Monkey patched in Fetch.		Not raised. Monkey patched in Fetch.

			== Content-Length ==

			In cases where Content-Length doesn't equal the actual content length, browsers truncate to the Content-Length value if it's smaller, but behaviour varies if Content-Length value is larger than actual content. Test results: https://github.com/slightlyoff/ServiceWorker/issues/362#issuecomment-49011736

	== Content-Type parsing ==		== Content-Type parsing ==

Annevk: /* Location header: duplicates */

2014-07-14T16:11:52Z

Location header: duplicates

← Older revision		Revision as of 16:11, 14 July 2014
Line 44:		Line 44:
	Nothing defines what happens with multiple Location headers. Apparently if their values match it is okay, but otherwise a network error.		Nothing defines what happens with multiple Location headers. Apparently if their values match it is okay, but otherwise a network error.

			== Location header: fragment ==

			https://bugzilla.mozilla.org/show_bug.cgi?id=1034819

	== Content-Location header ==		== Content-Location header ==

Annevk at 11:06, 30 June 2014

2014-06-30T11:06:48Z

← Older revision		Revision as of 11:06, 30 June 2014
Line 1:		Line 1:
	This page is an attempt to document some discrepancies between browsers and RFC 2068 (and its successor, RFC 2616) because the HTTP WG seems unwilling to resolve those issues. Hopefully one day someone writes HTTP5 and takes this into account.		This page is an attempt to document some discrepancies between browsers and RFC 2068 (and its successor, RFC 2616) because the HTTP WG seems unwilling to resolve those issues. Hopefully one day someone writes HTTP5 and takes this into account.


	== Content-Encoding ==		== Content-Encoding ==
Line 6:		Line 7:

	Not raised. Monkey patched in Fetch.		Not raised. Monkey patched in Fetch.


	== Content-Type parsing ==		== Content-Type parsing ==
Line 13:		Line 15:
	mnot: relevant spec - http://httpwg.github.io/specs/rfc7231.html#media.type I don't remember this being raised; we can either record it as errata or work it into the next revision.		mnot: relevant spec - http://httpwg.github.io/specs/rfc7231.html#media.type I don't remember this being raised; we can either record it as errata or work it into the next revision.

	http://mimesniff.spec.whatwg.org/#parsing-a-mime-type		'''Raised:''': http://www.rfc-editor.org/errata_search.php?rfc=7231&eid=4031

			Potential replacement: http://mimesniff.spec.whatwg.org/#parsing-a-mime-type


	== Redirects ==		== Redirects ==
Line 23:		Line 28:
	mnot: See http://httpwg.github.io/specs/rfc7231.html#status.3xx		mnot: See http://httpwg.github.io/specs/rfc7231.html#status.3xx

	== Location header ==		(Seems this is mostly solved now. Would still be good to explicitly require behavior here. Maybe in Fetch.)


			== Location header: URLs ==

	Browsers handle relative URIs and URIs with invalid characters in interoperable fashion.		Browsers handle relative URIs and URIs with invalid characters in interoperable fashion.
Line 29:		Line 37:
	'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/thread.html#msg276		'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/thread.html#msg276

	mnot: see note in: http://httpwg.github.io/specs/rfc7231.html#header.location		mnot: see note in: http://httpwg.github.io/specs/rfc7231.html#header.location If there's an updated URL spec that's able to be referenced when 7231 is revised, we can point at that.


			== Location header: duplicates ==

			Nothing defines what happens with multiple Location headers. Apparently if their values match it is okay, but otherwise a network error.

	~~If there's an updated URL spec that's able to be referenced when 7231 is revised, we can point at that.~~

	== Content-Location header ==		== Content-Location header ==
Line 40:		Line 52:

	This has apparently been fixed by making Content-Location have no UA conformance criteria. (It's not clear what it's good for at this point.)		This has apparently been fixed by making Content-Location have no UA conformance criteria. (It's not clear what it's good for at this point.)


	== Accept header ==		== Accept header ==
Line 46:		Line 59:

	(not raised, odinho: I came across a site that didn't like the spaces, the developer said he'd gotten it off php.net or stackoverflow. He fixed the site. This could be disputed.)		(not raised, odinho: I came across a site that didn't like the spaces, the developer said he'd gotten it off php.net or stackoverflow. He fixed the site. This could be disputed.)


	== Requiring two interoperable browser implementations ==		== Requiring two interoperable browser implementations ==
Line 55:		Line 69:
	mnot: That'll happen when RFC723x go to full Standard.		mnot: That'll happen when RFC723x go to full Standard.

	== Assume Vary: User-Agent ==
			== [Not an issue] Assume Vary: User-Agent ==

	UAs and intermediary caches should act as if all responses had Vary: User-Agent specified since many pages on the Web serve different content depending on the User-Agent header but do not bother specifying Vary: User-Agent.		UAs and intermediary caches should act as if all responses had Vary: User-Agent specified since many pages on the Web serve different content depending on the User-Agent header but do not bother specifying Vary: User-Agent.

GPHemsley: /* Content-Type parsing */ link to mimesniff algorithm

2014-06-26T19:44:44Z

Content-Type parsing: link to mimesniff algorithm

← Older revision		Revision as of 19:44, 26 June 2014
Line 12:		Line 12:

	mnot: relevant spec - http://httpwg.github.io/specs/rfc7231.html#media.type I don't remember this being raised; we can either record it as errata or work it into the next revision.		mnot: relevant spec - http://httpwg.github.io/specs/rfc7231.html#media.type I don't remember this being raised; we can either record it as errata or work it into the next revision.

			http://mimesniff.spec.whatwg.org/#parsing-a-mime-type

	== Redirects ==		== Redirects ==

Mnot at 06:12, 26 June 2014

2014-06-26T06:12:57Z

← Older revision		Revision as of 06:12, 26 June 2014
Line 10:		Line 10:

	Pretty sure I (Anne) raised this at some point. A trailing ";" after a MIME type is considered invalid, but works fine in all implementations.		Pretty sure I (Anne) raised this at some point. A trailing ";" after a MIME type is considered invalid, but works fine in all implementations.

			mnot: relevant spec - http://httpwg.github.io/specs/rfc7231.html#media.type I don't remember this being raised; we can either record it as errata or work it into the next revision.

	== Redirects ==		== Redirects ==
Line 16:		Line 18:

	'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/thread.html#msg225		'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/thread.html#msg225

			mnot: See http://httpwg.github.io/specs/rfc7231.html#status.3xx

	== Location header ==		== Location header ==
Line 22:		Line 26:

	'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/thread.html#msg276		'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/thread.html#msg276

			mnot: see note in: http://httpwg.github.io/specs/rfc7231.html#header.location

			If there's an updated URL spec that's able to be referenced when 7231 is revised, we can point at that.

	== Content-Location header ==		== Content-Location header ==
Line 42:		Line 50:

	'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/0222.html		'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/0222.html

			mnot: That'll happen when RFC723x go to full Standard.

	== Assume Vary: User-Agent ==		== Assume Vary: User-Agent ==
Line 50:		Line 60:

	:You may as well not have a cache if you do this. It's hard to find two users with the same User-Agent string if you try. It varies based on minor browser version, major OS version, and in old IE doesn't it vary based on installed plugins? Yes, some pages will break if you run a transparent caching proxy and don't vary based on UA, but it will be a small minority and somewhat random, and generally they'll fix themselves if you force-refresh. (Browsers send Cache-Control: no-cache when you force-refresh, which will skip a normally-configured cache.) Even if you vary based on UA, caching proxies will break some pages, because some sites serve incorrect caching headers and a caching proxy will make you hit these more often even in the single-user case. (E.g., hitting refresh will skip browser cache for the current page but not proxy cache, right?)<p>So basically, this is a performance vs. correctness tradeoff, and the correct answer for the vast majority of users is not to have a caching proxy at all. Some will want a caching proxy that serves them some incorrect pages. No one wants a caching proxy that varies based on UA, because then the cache will be useless. The only case I could think of where this might make sense is in an office with a homogeneous browser environment, which wants caching for its standard browsers (which all have the same UA string), but still wants to be relatively correct for people using Wi-Fi on their laptops with different browsers. But it's not something that makes any sense to require across the board. [[User:Aryeh Gregor\|Aryeh Gregor]] 08:45, 17 October 2012 (UTC)		:You may as well not have a cache if you do this. It's hard to find two users with the same User-Agent string if you try. It varies based on minor browser version, major OS version, and in old IE doesn't it vary based on installed plugins? Yes, some pages will break if you run a transparent caching proxy and don't vary based on UA, but it will be a small minority and somewhat random, and generally they'll fix themselves if you force-refresh. (Browsers send Cache-Control: no-cache when you force-refresh, which will skip a normally-configured cache.) Even if you vary based on UA, caching proxies will break some pages, because some sites serve incorrect caching headers and a caching proxy will make you hit these more often even in the single-user case. (E.g., hitting refresh will skip browser cache for the current page but not proxy cache, right?)<p>So basically, this is a performance vs. correctness tradeoff, and the correct answer for the vast majority of users is not to have a caching proxy at all. Some will want a caching proxy that serves them some incorrect pages. No one wants a caching proxy that varies based on UA, because then the cache will be useless. The only case I could think of where this might make sense is in an office with a homogeneous browser environment, which wants caching for its standard browsers (which all have the same UA string), but still wants to be relatively correct for people using Wi-Fi on their laptops with different browsers. But it's not something that makes any sense to require across the board. [[User:Aryeh Gregor\|Aryeh Gregor]] 08:45, 17 October 2012 (UTC)

			mnot: Yeah, that's a really bad idea.

	[[Category:Spec_coordination]]		[[Category:Spec_coordination]]

Annevk: /* Content-Type parsing */

2014-06-25T14:14:19Z

Content-Type parsing

← Older revision		Revision as of 14:14, 25 June 2014
Line 1:		Line 1:
	This page is an attempt to document some discrepancies between browsers and RFC 2068 (and its successor, RFC 2616) because the HTTP WG seems unwilling to resolve those issues. Hopefully one day someone writes HTTP5 and takes this into account.		This page is an attempt to document some discrepancies between browsers and RFC 2068 (and its successor, RFC 2616) because the HTTP WG seems unwilling to resolve those issues. Hopefully one day someone writes HTTP5 and takes this into account.

			== Content-Encoding ==

			Under certain conditions this header needs to be stripped: http://hg.mozilla.org/mozilla-central/file/366b5c0c02d3/netwerk/protocol/http/nsHttpChannel.cpp#l4042

			Not raised. Monkey patched in Fetch.

	== Content-Type parsing ==		== Content-Type parsing ==