Re: Squid and space char

The problem addressed by RFC1738 (I am working from my faulty memory) is
basically one of parsing, no?

METHOD<space>URL<space>VERSION

Now, in theory, everything after that second space is a version string
(like 'HTTP/1.0'). It's the browser's responsibility to encode spaces in
a URL as '+' or '%20', and not the proxy. Otherwise the proxy has to
perform more complicated parsing tricks on the request-line. Costs CPU
cycles. It's bad enough having the buggy clients out there now. Do we
really want to encourage a slew of browsers that burn even more of our
precious CPU cycles rather than doing it themselves, as they should?

D

Eli Beker wrote:
>
> Yep, I know blanks are not legal characters (RFC 1738). but
> users complain they're unable to download files with "spaces" in the URL.
> and without using the squid, the browser download the file with no
> problem.
>
> All spaces should be replaced with '%20'. I guess it can be done
> through an external redirector, but currently I'm using squirm and it
> doesn't handle such a rewrite rule.
> Any idea?
>
> Test this...
> >
> >(1) using netscape or explorer with ftp proxy configured
> >
> >(2) goto http://www.files.com
> >
> >(3) In the "find" dialog box, type "oscar" and click Find
> >
> >(4) In the listing that returns, click the first entry, namely
> >"COLTS 2.1 for Oscar.exe"
> >
> >(5) Click on this entry, Squid returns an error on RETR COLTS
>
> Regards,
> --Eli
> +--------------------------------------------------------------------+
> | Eli Beker http://www.ibm.net.il/~beker |
> | Unix System Admin. beker@ibm.net.il |
> | IBM Global Networking - IBM Israel Vnet: LBE at TELVM1 |
> | Phone : +972-3-6978687 Fax : +972-3-6978115 |
> +--------------------------------------------------------------------+

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E-
W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@ 
------END GEEK CODE BLOCK------