Re: processing of ICAP Transfer-Ignore options

On 04/15/2012 02:33 PM, Henrik Nordström wrote:
> lör 2012-04-14 klockan 19:11 -0600 skrev Alex Rousskov:
>
>> Sure, I am just trying to find a way to improve compatibility of ICAP
>> agents, even though the ICAP protocol itself is using wrong concepts
>> when defining what was meant as a pretty useful feature.
>
> I'd propose the following algorithm:
>
> 1. Look up content-type in the mime table and deduce file extension from
> there unless the content-type is application/octet-stream. Limited to
> mime table expressions on the form \.ext$ where ext do not contain any
> special regex patterns.

Are you saying that you want to use the Content-Type header as the
main guide for determining the "file extension" ?

I think that any change should stay close to the vague definitions
of the ICAP RFC. The text explaining the Transfer-Complete gives an
example of "bat" which is probable the old Windows .BAT command file
which probably has a Content-Type of text/plain.
IMO using the Content-Type will not have the desired behavior.

At the time that the ICAP RFC was written there were hardly any CGI scripts
and I believe that the intention was that the suffix of the URL was
the "file extension". Today, with the CGI parameters one could argue
that they should be stripped before determining the "file extension".

Anyway, clarity is the most important thing here and I suggest to
move this discussion to the ICAP discussion forum.

Marcus

> 2. For application/octet-stream or when the file extension is otherwise
> uncertain, identify the filename and derive file extension from there,
> in priority order
>
> a) Content-Disposition filename parameter
>
> b) URL-path
>
> c) Last part of query parameters
>
> With some handwaving and juggling to determine priority of b& c...
>
> Regards
> Henrik
>
>
>
Received on Mon Apr 16 2012 - 01:07:43 MDT