1 files changed, 16 insertions, 2 deletions

diff --git a/OpenSim/Capabilities/Handlers/GetTexture/GetTextureHandler.cs b/OpenSim/Capabilities/Handlers/GetTexture/GetTextureHandler.cs
index 4e755aa..7b4e957 100644
--- a/OpenSim/Capabilities/Handlers/GetTexture/GetTextureHandler.cs
+++ b/OpenSim/Capabilities/Handlers/GetTexture/GetTextureHandler.cs
@@ -196,11 +196,25 @@ namespace OpenSim.Capabilities.Handlers
                 int start, end;
                 if (TryParseRange(range, out start, out end))
                 {
-
                     // Before clamping start make sure we can satisfy it in order to avoid
                     // sending back the last byte instead of an error status
                     if (start >= texture.Data.Length)
                     {
+//                        m_log.DebugFormat(
+//                            "[GETTEXTURE]: Client requested range for texture {0} starting at {1} but texture has end of {2}",
+//                            texture.ID, start, texture.Data.Length);
+
+                        // Stricly speaking, as per http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html, we should be sending back
+                        // Requested Range Not Satisfiable (416) here.  However, it appears that at least recent implementations
+                        // of the Linden Lab viewer (3.2.1 and 3.3.4 and probably earlier), a viewer that has previously
+                        // received a very small texture  may attempt to fetch bytes from the server past the
+                        // range of data that it received originally.  Whether this happens appears to depend on whether
+                        // the viewer's estimation of how large a request it needs to make for certain discard levels
+                        // (http://wiki.secondlife.com/wiki/Image_System#Discard_Level_and_Mip_Mapping), chiefly discard
+                        // level 2.  If this estimate is greater than the total texture size, returning a RequestedRangeNotSatisfiable
+                        // here will cause the viewer to treat the texture as bad and never display the full resolution
+                        // However, if we return PartialContent (or OK) instead, the viewer will display that resolution.
+
 //                        response.StatusCode = (int)System.Net.HttpStatusCode.RequestedRangeNotSatisfiable;
                         // viewers don't seem to handle RequestedRangeNotSatisfiable and keep retrying with same parameters
                         response["int_response_code"] = (int)System.Net.HttpStatusCode.NotFound;
@@ -211,7 +225,7 @@ namespace OpenSim.Capabilities.Handlers
                         start = Utils.Clamp(start, 0, end);
                         int len = end - start + 1;
 
-                        //m_log.Debug("Serving " + start + " to " + end + " of " + texture.Data.Length + " bytes for texture " + texture.ID);
+//                        m_log.Debug("Serving " + start + " to " + end + " of " + texture.Data.Length + " bytes for texture " + texture.ID);
 
                         // Always return PartialContent, even if the range covered the entire data length
                         // We were accidentally sending back 404 before in this situation