Poll: Would you use header filters if they are implemented?
Yes, I have the necessary knowledge.
No, I don't have the knowledge, or I am too lazy.
No, I am doing just fine without them.
[Show Results]
Post Reply 
Header Filters
Feb. 16, 2006, 09:07 PM
Post: #1
Header Filters
Many Proxomitron users are asking for a "header filter" feature.
This feature would allow things like:
* Fixing a wrong Content-Type. Ever had a file opening as text instead of downloading?
* Forcibly enabling/disabling caching for certain pages.
* Some other things, most of which can be done with Firefox extensions.

Unfortunately, using this feature would require a deep understanding of the HTTP protocol.
So, I create a poll to get an idea of how much people want this feature.
This thread can also be used for general discussing of this feature, suggesting other uses of it, etc.
Add Thank You Quote this message in a reply
Mar. 14, 2006, 08:07 PM
Post: #2
Well, so far we have 5 people who would use header filters and 1 who is doing just fine without them. That one was actually me, and one of those 5 was tBB (the second moderator and a contributor to BFilter). When asked how he would use header filters, he said he would use them to fix broken content types, and nothing more.

Actually, broken content types cause problems for me as well. From time to time, after clicking a download link, the file is opened as text in the browser, instead of being downloaded. So I thought: why not solve this problem once and for all? Why not just hardcode a fix to BFilter? It would be very easy compared to adding the infrastructure for header filters, and every user would benefit from it.
The fix would work like this:
If the response Content-Type is text/plain, remove that header, unless the request URL ends with .txt
Actually it would work even without the .txt exception. In the absence of Content-Type, browsers try to guess it.

What do you guys think about it?
Add Thank You Quote this message in a reply
Apr. 05, 2006, 08:31 PM
Post: #3
Yes, I would like to see it in BFilter. At the moment there is lack of similar pleasant in using tools like that on Linux, and actually not all are using Firefox, some prefer Opera or other browsers.
About usage: it would be handy when it comes to removing session Id's, editing "on-fly" POST values, correcting browser/application settings. For example Privoxy doesn't have that feature well implemented it would help to correct some headers sent by it (connection: close, etc.) or setting site specific user-agent.

Greets, and good luck in developing. Smile!

\ page: http://www.noislet.org/
Quote this message in a reply
Apr. 05, 2006, 09:32 PM
Post: #4
Some of the things you'd like to do just can't be done with header filters, or at least can't easily be done.
For example, editing POST data requires a content filter rather than a header filter. In any case, a simple regex is not enough: you need to preserve the length of the request body or you need to update the Content-Length header to match the changed body size.

Another case:
Removing Connection: close or replacing it with Connection: keep-alive will do nothing but create troubles. When a client sets Connection: close, it can very well mean that the client doesn't support persistent connections at all. Actually, this is the case with IE's default configuration to use HTTP/1.0 for proxies.
When a server sets Connection: close, it can mean that it doesn't know the exact content length, and will close the connection to mark the end of content. In any case, it will close the connection whether you remove that header or not.

Here we see yet another reason why I resist adding this feature: it makes it very easy to shoot yourself in the foot. Besides Connection, there are several other headers that will create troubles when modified. Those include: Content-Length, Content-Encoding, Transfer-Encoding, Accept-Encoding, TE, and probably more.
Add Thank You Quote this message in a reply
May. 08, 2006, 09:54 AM
Post: #5
RE: Header Filters
About fixing the broken Content-Type again:
I made some research, and it turns out that among the browsers I tested (IE, Firefox, Opera, Safari), only Safari still believes Apache when it specifies Content-Type: text/plain. So, the problem has become almost non-existent by now.
Because I do most of my browsing in Safari, I decided to code a workaround anyway. It turned to be not that easy as I originally thought. I expected that in the absence of a Content-Type header, browsers would autodetect the type of content, but that was not the case. So, my code does the following:
if (<Content-Type: text/plain>) {
    <buffer the first 1K of content>;
    if (<content is mostly ascii> or <there are enough spaces>) {
        <leave Content-Type as is>;
    } else {
        <remove the Content-Type header>;
The workaround made it into the 0.10.4 version.
Add Thank You Quote this message in a reply
Post Reply 

Forum Jump: