Need another set of eyes... Mqc matching mime types

From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Fri Aug 05 2005 - 14:55:21 GMT-3


Okay, I labbed this up to my PC at home and did some testing. Hopefully
someone can shed some more light on the match protocol http options.
I need to understand why BOTH embedded jpeg images and URL jpeg images
(*.jpeg/*.jpg) are matched with the "match protocol http mime
image/jpeg"
I was expecting only embedded jpeg images to match, not jpeg images with
as a string in the URL. Afterall, isn't that what match protocol http
URL is for?
Here's the config I used:
class-map match-any mime
   match protocol http mime "image/jpeg"
policy-map qos
   class mime
      set ip precedence 2
int s0/0
  service in qos

Here is what I did:
Opened web browser to http://www.google.com
select "images" at the top
search for cisco
match counters increment as embedded jpeg results were returned to the
search page. This makes sense!
Then, I selected a jpeg image from the search results.
At this point, I was going to download the jpeg, so I cleared the
counters for the policy-map and selected the jpeg image to download.
The download began with *.jpeg/*.jpg in the URL string. The string is
as follows:
http://users.757.org/~ethan/pics/2-ebay/selling/cisco/cisco2.jpg
And checking the match counters I noticed they incremented on matching
mime types when *.jpg was in the URL
Does this mean that a match on MIME types will match on embedded images
AND the string URL?

The following shows the counters:
Serial0/0
Service-policy input: qos
Class-map: mime (match-any)
40 packets, 60160 bytes
5 minute offered rate 4000 bps, drop rate 0 bps
Match: protocol http mime "image/jpeg"
40 packets, 60160 bytes
5 minute rate 4000 bps
QoS Set
precedence 2
Packets marked 40
Class-map: class-default (match-any)
4 packets, 556 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any



This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:18 GMT-3