User:Thickbrick Sleaford/HTTP Texture Notes
Jump to navigation
Jump to search
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 relevant links:
- RFC 2616 section 14
- HTTP_Texture#Partial_Range
- Techwolf's analysis
- 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
- SVC-6396 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 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?
- SVC-6397 The response headers are missing Content-range: header, even when doing a ranged request.
- The request must have an "Accept: image/x-j2c" header for this to work.
- SVC-6073 The response headers contains Content-Type: text/html; charset=utf-8, even when delivering image/x-j2c.
- SVC-6069 Http GET texture not using keep-alive on sim side (nor client side, so nobody notices...)
- SVC-6096 HTTP-based caching of textures, meta issue.
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: [1] (and others.)
7.1
- Seems to work well.
- 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.)