Actually this issue is more like a limitation of Ziproxy than a bug itself.
The problem with both pages is this:
Content-Type: multipart/x-mixed-replace
Ziproxy's internal structure is not meant for individual chunk processing, it only sees the data as big file (not a series of text/html etc).
There are two possible approches:
1. - To force User-Agent: into something different than Mozilla/Firefox, like Konqueror.
This way, we'll force the httpd to send the data in the conventional way (broken in several files) since Apache thinks Konqueror (or another browser) does not support multipart/x-mixed-replace.
Unfortunately Apache ignores Accept: claiming multipart/x-mixed-replace as non-supported (it should not, but what can we do).
Apache uses User-Agent: in order to determine such capability, so we would need to change that.
The problem by doing this: there will be compatibility problems, or worse, some sites will simply refuse to work with a different user-agent.
2. - To simply allow gzipping of multipart/x-mixed-replace.
I'm not sure it's going to work properly.
Also, that would be only effective for text/* data though, and htmlopt and preemptdns won't work with such data still.
3. - To rewrite Ziproxy changing its structure into something more scalable, so we could treat such data properly.
Technically the best option, unfortunately I've got no time for such work.
Anyways, I'm open to ideas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1295112
Originator: NO
Actually this issue is more like a limitation of Ziproxy than a bug itself.
The problem with both pages is this:
Content-Type: multipart/x-mixed-replace
Ziproxy's internal structure is not meant for individual chunk processing, it only sees the data as big file (not a series of text/html etc).
There are two possible approches:
1. - To force User-Agent: into something different than Mozilla/Firefox, like Konqueror.
This way, we'll force the httpd to send the data in the conventional way (broken in several files) since Apache thinks Konqueror (or another browser) does not support multipart/x-mixed-replace.
Unfortunately Apache ignores Accept: claiming multipart/x-mixed-replace as non-supported (it should not, but what can we do).
Apache uses User-Agent: in order to determine such capability, so we would need to change that.
The problem by doing this: there will be compatibility problems, or worse, some sites will simply refuse to work with a different user-agent.
2. - To simply allow gzipping of multipart/x-mixed-replace.
I'm not sure it's going to work properly.
Also, that would be only effective for text/* data though, and htmlopt and preemptdns won't work with such data still.
3. - To rewrite Ziproxy changing its structure into something more scalable, so we could treat such data properly.
Technically the best option, unfortunately I've got no time for such work.
Anyways, I'm open to ideas.