User:Thickbrick Sleaford/HTTP Texture Notes - Revision history

Thickbrick Sleaford: /* OpenSim */

2011-05-06T20:49:07Z

OpenSim

← Older revision		Revision as of 13:49, 6 May 2011
Line 23:		Line 23:
	===OpenSim===		===OpenSim===
	====Up to and Including 0.7.0.2====		====Up to and Including 0.7.0.2====
	* Has a bug where the returned data will be one byte short of the requested data: [http://opensimulator.org/mantis/view.php?id=5081]		* Has a bug where the returned data will be one byte short of the requested data: [http://opensimulator.org/mantis/view.php?id=5081] (and others.)

	====~~Current Git Version~~====		====7.1====
			* Seems to work well.
	* The response has a proper ''Content-range:'' header.		* The response has a proper ''Content-range:'' header.
	* Returns 416 with an empty body if the range is not at least partially satisfiable (i.e. ''start >= length of file''.)		* Returns 416 with an empty body if the range is not at least partially satisfiable (i.e. ''start >= length of file''.)

Thickbrick Sleaford: /* Up to and Including 0.7.0.2 */

2010-11-11T23:03:31Z

Up to and Including 0.7.0.2

← Older revision		Revision as of 16:03, 11 November 2010
Line 23:		Line 23:
	===OpenSim===		===OpenSim===
	====Up to and Including 0.7.0.2====		====Up to and Including 0.7.0.2====
	* Has a bug where the returned data will be one byte short of the requested data.		* Has a bug where the returned data will be one byte short of the requested data: [http://opensimulator.org/mantis/view.php?id=5081]

	====Current Git Version====		====Current Git Version====
	* The response has a proper ''Content-range:'' header.		* The response has a proper ''Content-range:'' header.
	* Returns 416 with an empty body if the range is not at least partially satisfiable (i.e. ''start >= length of file''.)		* Returns 416 with an empty body if the range is not at least partially satisfiable (i.e. ''start >= length of file''.)

Thickbrick Sleaford: /* Second Life Servers */

2010-11-11T22:53:11Z

Second Life Servers

← Older revision		Revision as of 15:53, 11 November 2010
Line 9:		Line 9:

	===Second Life Servers ===		===Second Life Servers ===
	{{jira\|SVC-6396}} When asking for ranges that don't overlap the satisfiable byte range:		* {{jira\|SVC-6396}} When asking for ranges that don't overlap the satisfiable byte range:
	$ CAP=<GetTexture cap url>		$ CAP=<GetTexture cap url>
	$ UUID=<your texture's UUID>		$ UUID=<your texture's UUID>
Line 20:		Line 20:
	* {{jira\|SVC-6069}} Http GET texture not using keep-alive on sim side (nor client side, so nobody notices...)		* {{jira\|SVC-6069}} Http GET texture not using keep-alive on sim side (nor client side, so nobody notices...)
	* {{jira\|SVC-6096}} HTTP-based caching of textures, meta issue.		* {{jira\|SVC-6096}} HTTP-based caching of textures, meta issue.


	===OpenSim===		===OpenSim===

Thickbrick Sleaford at 22:50, 11 November 2010

2010-11-11T22:50:10Z

← Older revision		Revision as of 15:50, 11 November 2010
Line 2:		Line 2:
	My notes on what different server implementations do with GetTexture requests. Maybe this info is useful to someone else too.		My notes on what different server implementations do with GetTexture requests. Maybe this info is useful to someone else too.

	Some ~~other potentially~~ relevant ~~data~~:		Some relevant links:
	* [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1 RFC 2616 section 14]		* [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1 RFC 2616 section 14]
	* [[HTTP_Texture#Partial_Range]]		* [[HTTP_Texture#Partial_Range]]
	* [http://pastebin.com/Kc9x5BNS]		* [http://pastebin.com/Kc9x5BNS Techwolf's analysis]
			* [https://github.com/thickbrick/imprudence/compare/f2cf12d6bebd98434a0549f031beaac1ff2200c4...http_texture_experiment Relevant changesets in Imprudence 1.4] that try to make http fetching more robust and less reliant on assumptions that are not in the RFC

	===Second Life Servers ===		===Second Life Servers ===
	~~Range requests work as expected, returning status 216, except when~~ asking for ranges that don't overlap the satisfiable byte range:		{{jira\|SVC-6396}} When asking for ranges that don't overlap the satisfiable byte range:
	$ CAP=<GetTexture cap url>		$ CAP=<GetTexture cap url>
	$ UUID=<your texture's UUID>		$ UUID=<your texture's UUID>
	$ N=<The known filesize of the texture>		$ N=<The known filesize of the texture>
	$ curl --range $N-99999999 --header "Accept: image/x-j2c" -D headers.txt "${CAP}/?texture_id=${UUID}" -o image.j2c		$ curl --range $N-99999999 --header "Accept: image/x-j2c" -D headers.txt "${CAP}/?texture_id=${UUID}" -o image.j2c
	Returns the whole texture, with status code 216. What it should do is return status code 416. (See [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1 RFC 2616]). This may mean that the viewer can't do ranged requests with ranges not beginning the the beginning of the file and expect it to work properly? ~~See also~~ {{jira\|SVC-~~6396~~}}.		Returns the whole texture, with status code 216. What it should do is return status code 416. (See [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1 RFC 2616]). This may mean that the viewer can't do ranged requests with ranges not beginning the the beginning of the file and expect it to work properly?
			* {{jira\|SVC-6397}} The response headers are missing ''Content-range:'' header, even when doing a ranged request.
	~~Other notes:~~
	* The response headers are missing ''Content-range:'' header, even when doing a ranged request. ~~{{jira\|SVC-6397}}~~
	* The request must have an ''"Accept: image/x-j2c"'' header for this to work.		* The request must have an ''"Accept: image/x-j2c"'' header for this to work.
	* The response headers contains ''Content-Type: text/html; charset=utf-8'', even when delivering image/x-j2c.		* {{jira\|SVC-6073}} The response headers contains ''Content-Type: text/html; charset=utf-8'', even when delivering image/x-j2c.
			* {{jira\|SVC-6069}} Http GET texture not using keep-alive on sim side (nor client side, so nobody notices...)
			* {{jira\|SVC-6096}} HTTP-based caching of textures, meta issue.


Line 25:		Line 26:
	* Has a bug where the returned data will be one byte short of the requested data.		* Has a bug where the returned data will be one byte short of the requested data.
	====Current Git Version====		====Current Git Version====
	* The response has a proper ~~byte ranges~~ header.		* The response has a proper ''Content-range:'' header.
	* Returns 416 with an empty body if the range is not at least partially satisfiable (i.e. ''start >= length of file''.)		* Returns 416 with an empty body if the range is not at least partially satisfiable (i.e. ''start >= length of file''.)

Thickbrick Sleaford: /* HTTP Texture Fetching on Different Servers */

2010-10-12T01:10:18Z

HTTP Texture Fetching on Different Servers

← Older revision		Revision as of 18:10, 11 October 2010
Line 2:		Line 2:
	My notes on what different server implementations do with GetTexture requests. Maybe this info is useful to someone else too.		My notes on what different server implementations do with GetTexture requests. Maybe this info is useful to someone else too.

	Some other relevant data:		Some other potentially relevant data:
	* [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1 RFC 2616 section 14]		* [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1 RFC 2616 section 14]
	* [[HTTP_Texture#Partial_Range]]		* [[HTTP_Texture#Partial_Range]]
			* [http://pastebin.com/Kc9x5BNS]

	===Second Life Servers ===		===Second Life Servers ===

Thickbrick Sleaford: Created page with '==HTTP Texture Fetching on Different Servers== My notes on what different server implementations do with GetTexture requests. Maybe this info is useful to someone else too. Some...'

2010-10-12T00:47:47Z

Created page with '==HTTP Texture Fetching on Different Servers== My notes on what different server implementations do with GetTexture requests. Maybe this info is useful to someone else too. Some...'

New page

==HTTP Texture Fetching on Different Servers==
My notes on what different server implementations do with GetTexture requests. Maybe this info is useful to someone else too.

Some other relevant data:
* [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1 RFC 2616 section 14]
* [[HTTP_Texture#Partial_Range]]

===Second Life Servers ===
Range requests work as expected, returning status 216, except when asking for ranges that don't overlap the satisfiable byte range:
$ CAP=<GetTexture cap url>
$ UUID=<your texture's UUID>
$ N=<The known filesize of the texture>
$ curl --range $N-99999999 --header "Accept: image/x-j2c" -D headers.txt "${CAP}/?texture_id=${UUID}" -o image.j2c
Returns the whole texture, with status code 216. What it should do is return status code 416. (See [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1 RFC 2616]). This may mean that the viewer can't do ranged requests with ranges not beginning the the beginning of the file and expect it to work properly? See also {{jira|SVC-6396}}.

Other notes:
* The response headers are missing ''Content-range:'' header, even when doing a ranged request. {{jira|SVC-6397}}
* The request must have an ''"Accept: image/x-j2c"'' header for this to work.
* The response headers contains ''Content-Type: text/html; charset=utf-8'', even when delivering image/x-j2c.

===OpenSim===
====Up to and Including 0.7.0.2====
* Has a bug where the returned data will be one byte short of the requested data.
====Current Git Version====
* The response has a proper byte ranges header.
* Returns 416 with an empty body if the range is not at least partially satisfiable (i.e. ''start >= length of file''.)