RE: match protocol http [ url vs mime ]

From: Scott Morris (swm@emanon.com)
Date: Thu Nov 11 2004 - 19:50:53 GMT-3


No, only the mime will work since the word "images" may or may not be in
your URL (only if someone stores all graphics in a /images directory
(instead of /image or something else)...

Take a sniffer sometime (ethereal is good and free!) and look at all the
web requests that your station makes when you browse the web. Then look
specifically at the URLs that are requested. Go to a few different sites
and you'll see the variety on why this is hard.

MIME types are fairly standard.

HTH,

Scott

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: Thursday, November 11, 2004 4:57 PM
To: Andy
Cc: Group Study
Subject: Re: match protocol http [ url vs mime ]

Andy,

Thanks again for getting back to me.

Just let me make sure I fully understand you.

If I want to block web surfers from seeing any pictures in any format I
would do this:

class-map IMAGES
     match prot http url "*images*"
or
    match prot http mime "*images*"

Either one will work, but the 1st one is more efficient. Have I got that
right?

Now, is it possible using just 1 single match prot http command to specify
both jpeg and bmp or do I need multiple match prot statements?

For example, will this work?

class-map JPEG-&-BMP
    match prot http mime "*jpeg | *bmp"

Thanks, Tim

----- Original Message -----
From: "Andy" <AndyMrozek@yahoo.com>
To: "'ccie2be'" <ccie2be@nyc.rr.com>; <swm@emanon.com>; "'Group Study'"
<ccielab@groupstudy.com>
Sent: Thursday, November 11, 2004 3:43 PM
Subject: RE: match protocol http [ url vs mime ]

> I have tried both url / mime type ... Both work ,as I have webserver and
> traffic generator .. In my opionon though I would use mime type as it
seems
> to drop it alot faster , and doesnt use as many network resourced , with a
> sniffer in the path between client / server you see lots of attempts from
> client to keep pulling information when using url type , but only a few
when
> using mime type , the only thing I thing about mime type we need to know
the
> various image types for example I had done "*image*" and it was blocking
> .bmp , .jpg, .gif so if you only are required to say block .bmp I think
then
> you can use mime type unless there is a way to only block .bmp mime type
but
> say let .jpg through...
>
> -Andy
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> ccie2be
> Sent: Thursday, November 11, 2004 12:27 PM
> To: swm@emanon.com; 'Group Study'
> Subject: Re: match protocol http [ url vs mime ]
>
>
> Hi Scott,
>
> Thanks for getting back to me.
>
> Before I posted the questions below I did a google and found the rfc for
> mime. Here's the link for anyone interested:
>
> http://www.mhonarc.org/~ehood/MIME/2045/rfc2045.html
>
> I started reading it but after a while my eyes glazed over and I didn't
find
> anything that actually helped me figure out whether I should use the url
or
> mime parameter of the match prot http command to accomplish this task.
>
> Maybe my brain isn't in good working order at the moment, but after
reading
> your response, I'm still not sure whether I should use the url or mime
> parameter in the match protocol http command to classify jpeg's, gif's,
> mpeg's, etc.
>
> So, let's say I want to block web surfers from downloading jpeg's and
avi's.
>
> Would I use
>
> match prot http url "*jpeg | *avi"
>
> or
>
> match prot http mime "*jpeg | *avi"
>
> Notice that I used the bar | to specify either jpeg OR avi. Is that OK?
>
> Thanks, Tim
>
> ----- Original Message -----
> From: "Scott Morris" <swm@emanon.com>
> To: "'ccie2be'" <ccie2be@nyc.rr.com>; "'Group Study'"
> <ccielab@groupstudy.com>
> Sent: Thursday, November 11, 2004 2:32 PM
> Subject: RE: match protocol http [ url vs mime ]
>
>
> > The protocol type represents a field within the HTTP structures... It
> will
> > never look like "*.jpeg". That's a filename call, and within the URL.
> >
> > MIME types are "image/jpeg", "image/gif", "video/avi" and things like
> > that... There's an RFC about Multimedia Independent Mail Extensions
> (MIME),
> > but I don't recall what its number is...
> >
> > Otherwise, take a look at your File Associations table in Windows and
> you'll
> > have an idea for different MIME types and their name.
> >
> > HTH,
> >
> >
> > Scott Morris, MCSE, CCDP, CCIE4 (R&S/ISP-Dial/Security/Service Provider)
> > #4713, JNCIP, CCNA-WAN Switching, CCSP, Cable Communications Specialist,
> IP
> > Telephony Support Specialist, IP Telephony Design Specialist, CISSP
> > CCSI #21903
> > swm@emanon.com
> >
> >
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > ccie2be
> > Sent: Thursday, November 11, 2004 12:31 PM
> > To: Group Study
> > Subject: match protocol http [ url vs mime ]
> >
> > Hi guys,
> >
> > I need some help figuring out when to use the "mime" parameter when
> matching
> > traffic.
> >
> > For example, if I want to apply a policy which filters or restricts
> traffic
> > that contains jpeg files which config should I use?
> >
> > class-map jpeg
> > match protocol http url "*.jpeg"
> >
> > or
> >
> > match protocol http mime "*.jpeg"
> >
> >
> > Also, can regular expressions be used within the quote marks?
> >
> > For example, is this OK?
> >
> > match prot http mime "*.jpeg | *.jpg | *.mpeg"
> >
> >
> > Any insight or help is greatly appreciated.
> >
> > TIA, Tim
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Thu Dec 02 2004 - 06:57:42 GMT-3