Hi Leif,
On the first range request it works in deed, the problem arises - at least
in my case - when the full file is cached by a previous request and the
range is served from the cache. I attached my heavily modified gzip (now
null-transform) plugin I used to test it.
Best Regards,
Sebastian
-
Realistically, I would estimate end of August as a reasonable time frame.
Thursday, August 8, 2013, 7:36:43 PM, you wrote:
> I'm glad that the problem is at least known.
> Do you have a gut-feeling when you will find the time? Is it rather this
> month, in the next 3 months, this year or rather i
s.com]
Gesendet: Donnerstag, 8. August 2013 14:50
An: Sebastian Annies
Betreff: Re: AW: Plugin transforming between cache and end-user
The range transforms worked at for 3.0 but were broken for 3.2. This was
masked by the addition of range acceleration but when that was determined
to be too risk
The range transforms worked at for 3.0 but were broken for 3.2. This was masked
by the addition of range acceleration but when that was determined to be too
risky the original range transform issue was re-exposed. I'm currently trying
to get some time to work on that, I see what the problem is,
Hi,
So far I'm happy with everything except HTTP range requests.
Whenever the plugin is null-transforming a HTTP range request the
following is happening:
* the return code is set to 200 (instead of 206)
* the content-range header is omitted
* nevertheless the plugin only 'sees' the requested byt
Hi,
On IRC someone suggested (sorry I forgot your name!) to start looking at
the gzip plugin as it stores the full data and perform the
compression/transformation on the fly. I removed everything and modified
so that I now have a null-transform that also works on cached content. I
have a good star
