As we're on the subject of supporting range requests, I have a substantive patch at
https://github.com/SolidWallOfCode/trafficserver/tree/range which attempts to fix the current range issue with alternates. This patch moves the fragment offset table from the Doc header to the alternate info. This means the offsets are stored per alternate and therefore there is no longer a potential mismatch between that data and the actual alternate content. It works for me, but I have the magic dev box where everything works. I will be doing further testing but if anyone else wants to take a look ... Beyond normal clean up (e.g., remove the debug "amc" messages) my primary concern is that ats_malloc is used. This is how the current implementation works but it seems suboptimal. OTOH ats_malloc is called only during writes on objects larger than 4 segments (>5M total length in the default configuration). It's not clear how much performance is relatively impacted by the call for objects that large. There is a heap associated with the alternate info object which may be usable instead, which I hope to be able to investigate although as always hints are appreciated.
