aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/OpenSim/Capabilities/Handlers/GetTexture/GetTextureHandler.cs (follow)
Commit message (Collapse)AuthorAgeFilesLines
* minor: change method doc on GetTextureHandler.TryParseRange(), mainly to ↵Justin Clark-Casey (justincc)2012-12-061-2/+2
| | | | trigger another build
* Allow GetTexture calls with no second value in the range header (e.g. just ↵Justin Clark-Casey (justincc)2012-12-061-1/+34
| | | | | | | | 5333-) It looks like the latest Kokua is doing this. As per http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html, leaving off the second value is legal This indicates the caller wants the rest of the entity.
* minor: Comment out "Client requested range for texture ... but" message. ↵Justin Clark-Casey (justincc)2012-10-121-3/+3
| | | | This is not useful during normal operation.
* If the GetTexture capability receives a request for a range of data beyond ↵Justin Clark-Casey (justincc)2012-09-061-5/+29
| | | | | | | | | | that of an otherwise valid asset, return HTTP PartialContent rather than RequestedRangeNotSatisfiable. This is because recent viewers (3.2.1, 3.3.4) and probably earlier ones using the http GetTexture capability will sometimes make such invalid range requests. This appears to happen if the viewer's estimate of texture sizes at discard levels > 0 (chiefly 2) exceeds the total texture size. I believe this does not normally happen but can occur for dynamic textures with are large but mainly blank. If this happens, returning a RequestedRangeNotSatisfiable will cause the viewer to not render the texture at the final resolution. However, returning a PartialContent (or OK) even with 0 data will allow the viewer to render the final texture.
* Don't include time to transmit response back to requester when assessing ↵Justin Clark-Casey (justincc)2012-06-131-2/+0
| | | | | | | | | | slow handling of requests. This is to avoid logging a 'slow' request when the source of delay is the viewer in processing a response. This is not something we can do much about on the server end - it's server-side delay that we're interested in. To ensure consistency, this commit also had to refactor and simplify inbound non-poll network request handling, though there should be no functional change. IOSHttpResponse no longer exposes the Send() method, only classes in OpenSim.Framework.Servers.HttpServer should be doing this. Only the GetTextureHandler was sending its own response. Now it leaves this to BaseHttpServer, like all other core handlers.
* Implement optional name and description on http stream handlers so that we ↵Justin Clark-Casey (justincc)2012-05-031-2/+2
| | | | | | can relate a slow request to what the handler actually does and the agent it serves, if applicable. This is most useful for capabilities where the url is not self-describing.
* Add commented log lines to FetchInventoryDescendents2 path for future use.Justin Clark-Casey (justincc)2011-12-091-3/+9
| | | | Haven't been able to resolve issue where attachments are removed by the viewer on relog on a localhost
* Implement IOSHttpRequest and IOSHttpResponse http interfaces and use instead ↵Justin Clark-Casey (justincc)2011-12-051-3/+3
| | | | | | | | of OSHttpRequest/OSHttpResponse. This is required for the substitution of different HTTP servers or the newer HttpServer.dll without having to commit to a particular implementation. This is also required to write regression tests that involve the HTTP layer. If you need to recompile, all you need to do is replace OSHttpRequest/OSHttpResponse references with IOSHttpRequest/IOSHttpResponse.
* For the GetTexture capability, if a data range is requested that covers the ↵Justin Clark-Casey (justincc)2011-12-051-14/+25
| | | | | | | | | | whole asset length, return HTTP PartialContent instead of NotFound NotFound is obviously wrong, and this change stops viewer 3.2.2 (and v probably earlier) complaining in the log about missing textures that are actually present. We still return PartialContent even if the range requested is a superset of the data range as per httpd's behaviour https://issues.apache.org/bugzilla/show_bug.cgi?id=51878 Viewer 3.2.2 and very probably earlier appear happy with this. Whether fixing this NotFound bug has any practical effect apart from resolve viewer log messages is unknown.
* refactor: Separate the upload baked texture handler out from BunchOfCapsJustin Clark-Casey (justincc)2011-12-011-3/+1
|
* Save the default terrain texture UUIDs for a new region instead of leaving ↵Justin Clark-Casey (justincc)2011-09-091-3/+2
| | | | | | | | | | | them as UUID.Zero. Leaving them at UUID.Zero meant that when a viewer 2 logged into a region that had been freshly created, it received UUID.Zero for these textures, and hence display the land as plain white. On a simulator restart, the problem would go away since when the database adapators loaded the new region settings, RegionSettings itself has code to use default textures instead of UUID.Zero. This commit resolves the problem by saving the default texture UUIDs instead of Zero. However, we currently have to do this in a roundabout way by resaving once the RegionSettings have been created by the database for the first time. This needless complexity should be addressed. This change will also have the effect of replacing any existing UUID.Zero terrain textures with the default ones. However, this shouldn't have any effect since the UUID.Zeros were already being replaced in memory with those same UUIDs.
* Comment verbose debug message in GetTextureDiva Canto2011-05-081-1/+1
|
* Refactored the GetMesh module into a handler and a module, to be the same as ↵Diva Canto2011-05-021-0/+357
GetTexture.