It seems ok to me. why not put it in the TS-1339, so that we all can reviews and test it.
On Mon, 2012-08-20 at 11:31 -0500, Alan M. Carroll wrote: > 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. >