Post Reply 
Say what you will about MIME types.....
Nov. 25, 2008, 08:13 AM
Post: #1
Say what you will about MIME types.....
Gang;

We sometimes bounce off the topic of MIME types, and how to correct them when they don't "play nice". (See Graycode's recent example, here - check out the Content-Type header.)

While surfing for something else entirely different, I tripped across the NirSoft website, wherein there are over a hundred small utilities for various purposes. One that caught my eye (you didn't think I'd just leave without checking out the goodies, did you? Wink ) was something that displays all the MIME types loaded into your system. Looky here:

http://www.nirsoft.net/utils/mimeview.html

It should give a clue as to what your system is expecting when the browser asks for "handler X", and yet you get garbage. The question that should be answerable, thanks to this utility, is what handler is being thrown to the browser, and if it's wrong, what handler should it be? Armed with that info, writing a filter the corrects the header to call the proper handler should be a whole lot easier. Big Teeth

HTH



Oddysey

I'm no longer in the rat race - the rats won't have me!
Add Thank You Quote this message in a reply
Nov. 25, 2008, 01:35 PM
Post: #2
RE: Say what you will about MIME types.....
Thanks for the software Oddisey ;)

Speaking about "Content-Type: Fix MIME Types":
This is a non stand alone filter in sidki's wich gave more problems than good results when i imported it to my config...
In sidki's there is another filter i don't know wich fixes some problems. One example is when you click on a link like http://www.rapidshare.com....file.rar That link gives you to an html page where you have to select free user or premium for downloading the page. But it was giving me the html page as the rar file.

The other day we saw the logo from McAfee coded like unicode, and the image will be perfectly seen in our browsers. But If we change all the jpg links to content-type:image/jpeg then we won't see html files wich later links to the real image...

I had also problems with charsets, so I had to change the code to not add "; old content-type"

I would use this filter only when content-type is for something executable, yesterday i received a malicious favicon.ico coded as this. As the favicon.ico will no break anything would be safer to receive it only if is an image, other many times we receive error 404 pages but we could kill this page safely with \k...

MIME-list.ptxt is coded to change always the MIME-type, neither import if it was correct before or not. I changed it to work only when needed and to see it in the log window. Examples are:
rar $SET(0=application/x-rar-compressed)
mine is:rar (^$TST(\2=application/x-rar-compressed))$SET(0=application/x-rar-compressed)

Another thing i'm not pretty sure is writing only application/* or audio/* or image/* etc without needing to specify the part after the /

I still don't know well how the browser works with the content-type, so i didn't modify more the filter as i would like. All i wrote here is all i lerned testing don't know more about MIME..hope this help someone anyday...
Add Thank You Quote this message in a reply
Nov. 25, 2008, 02:22 PM
Post: #3
RE: Say what you will about MIME types.....
(Nov. 25, 2008 01:35 PM)lnminente Wrote:  yesterday i received a malicious favicon.ico

too dang funny...
my "excessive paranoia" wins through again...

i BLOCK STUPID favicons!!!


Code:
[HTTP headers]
In = FALSE
Out = TRUE
Key = "Cookie: 3 Kill FavIcon Requests (Out) [add]"
URL = "*/favicon.ico"
Replace = "killed FavIcon request\k"

Code:
[Patterns]
Name = "Block: FavIcon Cookies [add]"
Active = TRUE
URL = "$IHDR(Content-Type: (*(html|xml)*))"
Bounds = "<link\s[^>]++re(l|v)=$AV((shortcut |)icon)[^>]+>"
Limit = 300
Match = "*"
Add Thank You Quote this message in a reply
Nov. 25, 2008, 04:53 PM (This post was last modified: Nov. 25, 2008 05:22 PM by lnminente.)
Post: #4
RE: Say what you will about MIME types.....
I will try the first and maybe modify it a bit to only allow if their content type is image/*
To the second filter i think we could add $STOP()

Many thanks for both filters ProxRocks Wink

Said and made Smile!
Code:
[HTTP headers]
In = TRUE
Out = FALSE
Key = "Content-Type: Kill non image FavIcons {ln}081125b (in)"
URL = "*/favicon.ico"
Match = "\1&(^ image/*)"
Replace = "$RDIR(http://local.ptron/red.gif)$LOG(R$DTM(c): Killed non image FavIcon - Content-type: \1) \k"


mmhh I like your URL code: $IHDR(Content-Type: (*(html|xml)*))
It could be an improvement over $TYPE(htm) sometimes
Add Thank You Quote this message in a reply
Nov. 25, 2008, 06:18 PM
Post: #5
RE: Say what you will about MIME types.....
(Nov. 25, 2008 04:53 PM)lnminente Wrote:  To the second filter i think we could add $STOP()

i've never "fully" understood 'where' those $STOP's are 'supposed' to be, i've seen them in the URL line, the Match line, and the Replace line...
Add Thank You Quote this message in a reply
Nov. 25, 2008, 08:25 PM
Post: #6
RE: Say what you will about MIME types.....
The $STOP() is not something like PrxFail$TST(), his function is to use only one time this filter for every connection. You can put them everywhere.
Here is all the info you need about $STOP()

From the help http://www.proxomitron.info/45/help/Matc....html#STOP

http://www.proxomitron.info/45/help Wrote:$STOP()
Restrictions: Match or Replace
Filter Types: All
$STOP is a very simple command. If encountered in either the match or replace of a filter $STOP will turn that filter off for the rest of the page/connection. The current match will be allowed to complete, but once that happens, no further matching will be done on that filter.

This can be very useful for filters you only want to match once. Especially ones that insert something into a page at a given point. For example, say you wanted to insert a small script after the <BODY> tag. You could use...

Match: <body\s \1>
Replace: <body \1>
<script>my script</script>
$STOP( )

Not only does this insure the script will only be inserted once, but it also speeds things up since Proxomitron doesn't have to waste time checking for it anymore. Also note that $STOP will now do its thing even if the filter as a whole doesn't match as long as it's called at some point in the matching process.

From techniques.txt of Sidki
sidkis technique Wrote:8 You can stop a filter without letting it match as a whole by placing $STOP()
anywhere before the match fails -- $STOP() is always processed when
encountered.
In below examples PrxFail$TST() is used to force match failure, even if a
web page should "accommodate" to public Proxomitron filters. $TST() never
matches, but is a bit slow and only processed in latter scenario.

Examples:
$STOP()$SET(foo=bar)DontMatchMe sets stop, sets foo=bar, match fails

(
$TST(var=true) if var is "true" process match_expr,
|(^$TST(var=true))$STOP()PrxFail$TST() else set stop and fail match
)
match_expr
Add Thank You Quote this message in a reply
Nov. 25, 2008, 08:28 PM
Post: #7
RE: Say what you will about MIME types.....
ah, now that was toooo easy, lol...
Add Thank You Quote this message in a reply
Post Reply 


Forum Jump: