Re: processing of ICAP Transfer-Ignore options

On 17/04/2012 12:40 a.m., Marcus Kool wrote:
>
> On 04/16/2012 04:34 AM, Henrik Nordström wrote:
>> sön 2012-04-15 klockan 22:07 -0300 skrev Marcus Kool:
>>
>>> Are you saying that you want to use the Content-Type header as the
>>> main guide for determining the "file extension" ?
>>
>> Yes, when there is a usable content-type.
>
> The idea itself is good. The problem is that it is very different
> than what the ICAP RFC states. I think that the negation of filtering
> based on Content-Type should use a new parameter, e.g.
> Ignore-Content-Type.
>
> And lets not forget that Transfer-Ignore based on a part of the URL
> can be used for REQMOD and RESPMOD while Ignore-Content-Type can
> only be used for RESPMOD.
> This has a small performance impact: there will be more ICAP traffic
> since less can be ignored.
>
>>> Anyway, clarity is the most important thing here and I suggest to
>>> move this discussion to the ICAP discussion forum.
>>
>> Clarity in a pile of mud...
>
> Hahaha. Do you propose to make a ICAP2 standard that is not backwards
> compatible?
>
>> Regards
> Marcus

I have a number of clients dealing with this most common case among the
popular CMS systems today...

GET http://example.com/index.php?some/file.jpg HTTP/1.1
...
HTTP/1.1 200 Okay
Content-Type: text/xml
...
GET http://example.com/imagews/1861245634-230is86 HTTP/1.1
...
HTTP/1.1 200 Okay
Content-Type: image/jpeg
...

If one is lucky the CMS *may* put .jpg on the second URI name.

Amos
Received on Mon Apr 16 2012 - 13:00:28 MDT