[jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[Richard Stallman]

Could someone please DTRT and ack?

------- Start of forwarded message -------
From: Dan Jacobson <jidanni@jidanni.org>
To: bug-gnu-emacs@gnu.org
Date: Tue, 06 Jun 2006 05:07:46 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: browse-url-of-dired-file vs. .gz
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

browse-url-of-dired-file on file.html.gz doesn't first uncompress it.


_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

[jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[Richard Stallman]

[I sent this message a week ago but did not get a response.]

Could someone please DTRT and ack?

------- Start of forwarded message -------
From: Dan Jacobson <jidanni@jidanni.org>
To: bug-gnu-emacs@gnu.org
Date: Tue, 06 Jun 2006 05:07:46 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: browse-url-of-dired-file vs. .gz
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

browse-url-of-dired-file on file.html.gz doesn't first uncompress it.


_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

Re: [jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Could someone please DTRT and ack?
>
> From: Dan Jacobson <jidanni@jidanni.org>
> Subject: browse-url-of-dired-file vs. .gz
> To: bug-gnu-emacs@gnu.org
>
> browse-url-of-dired-file on file.html.gz doesn't first uncompress it.

This is a known Firefox bug, see

  https://bugzilla.mozilla.org/show_bug.cgi?id=52282

This bug has nothing to do with Emacs; opening file:///foo/bar.html.gz
in the Firefox address bar fails to uncompress, whereas
http://foo/bar.html.gz uncompress properly.  I don't think there's
anything we can (or should) do in Emacs to work around this.  The
Mozilla folks are still discussing how to fix it on their end.

[jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[Richard Stallman]

[I sent this message twice but did not get a response.]

Could someone please DTRT and ack?

------- Start of forwarded message -------
From: Dan Jacobson <jidanni@jidanni.org>
To: bug-gnu-emacs@gnu.org
Date: Tue, 06 Jun 2006 05:07:46 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: browse-url-of-dired-file vs. .gz
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

browse-url-of-dired-file on file.html.gz doesn't first uncompress it.


_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

Re: [jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> [I sent this message twice but did not get a response.]
>
> Could someone please DTRT and ack?
>
> From: Dan Jacobson <jidanni@jidanni.org>
> Subject: browse-url-of-dired-file vs. .gz
> To: bug-gnu-emacs@gnu.org
>
> browse-url-of-dired-file on file.html.gz doesn't first uncompress it.

You must have missed my previous message:

  This is a known Firefox bug, see

    https://bugzilla.mozilla.org/show_bug.cgi?id=52282

  This bug has nothing to do with Emacs; opening
  file:///foo/bar.html.gz in the Firefox address bar fails to
  uncompress, whereas http://foo/bar.html.gz uncompress properly.  I
  don't think there's anything we can do in Emacs to work around this.
  The Mozilla folks are still discussing how to fix it on their end.

Re: [jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[Stuart D. Herring]

> browse-url-of-dired-file on file.html.gz doesn't first uncompress it.

I don't think this is an Emacs bug, precisely, since Emacs shouldn't be
uncompressing that file.  But is it a bug that

(browse-url-file-url "/foo.bar")

gives "file:/foo.bar" and not "file:///foo.bar"?

It seems to me that the last element of `browse-url-filename-alist' should
just be

("^/+" . "file:///")

If I'm not mistaken and this is wrong, perhaps it's confusing the browser?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: [jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[Lennart Borgman]

Stuart D. Herring wrote:
>> browse-url-of-dired-file on file.html.gz doesn't first uncompress it.
>>     
>
> I don't think this is an Emacs bug, precisely, since Emacs shouldn't be
> uncompressing that file.  But is it a bug that
>
> (browse-url-file-url "/foo.bar")
>
> gives "file:/foo.bar" and not "file:///foo.bar"?
>
> It seems to me that the last element of `browse-url-filename-alist' should
> just be
>
> ("^/+" . "file:///")
>
> If I'm not mistaken and this is wrong, perhaps it's confusing the browser?
>
> Davis
>   
I have posted some complaints about browse-url-filename-alist 
previously. Please take a look here:

    http://lists.gnu.org/archive/html/emacs-devel/2006-06/msg00613.html

Re: [jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[Jason Rumney]

Stuart D. Herring wrote:
> But is it a bug that
>
> (browse-url-file-url "/foo.bar")
>
> gives "file:/foo.bar" and not "file:///foo.bar"?
>
>   
Both are equally valid URLs for a local file.

Re: [jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[Lennart Borgman]

Jason Rumney wrote:
> Stuart D. Herring wrote:
>> But is it a bug that
>>
>> (browse-url-file-url "/foo.bar")
>>
>> gives "file:/foo.bar" and not "file:///foo.bar"?
>>
>>   
> Both are equally valid URLs for a local file.
Thanks for that info. That clears my confusion a bit. But where is this 
info? I did a search at w3c.org but did not find it.

Re: [jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[Jason Rumney]

Lennart Borgman wrote:
> Jason Rumney wrote:
>> Both are equally valid URLs for a local file.
> Thanks for that info. That clears my confusion a bit. But where is 
> this info? I did a search at w3c.org but did not find it.

People used to discuss this regularly in the early days of web browsers, 
when bugs in browser implementations meant you needed to be familiar 
with all the possibilities (some browsers used to use ftp if there were 
two or more slashes after file:).

http://groups.google.co.uk/group/comp.infosystems.www.providers/browse_thread/thread/d6642ca04fc461c4/dcbe395dc34c2c92?lnk=st&q=file+url+local&rnum=23&hl=en#dcbe395dc34c2c92

However, I just reviewed the relevant  RFCs, and there is no mention of 
a server-less version of the file: URL scheme, so file:/// does appear 
be more correct than file:/, at least in theory.

Re: [jidanni@jidanni.org: browse-url-of-dired-file vs. .gz]

[Stuart D. Herring]

> However, I just reviewed the relevant  RFCs, and there is no mention of
> a server-less version of the file: URL scheme, so file:/// does appear
> be more correct than file:/, at least in theory.

Page 21 of RFC 3986 states that

                                 For example, the "file" URI
   scheme is defined so that no authority, an empty host, and
   "localhost" all mean the end-user's machine, ...

"No authority" means that the "//host" part of the URI is omitted
entirely, whereas "an empty host" means that the "//" has no text between
it and the following "/" that begins the path (which, with an authority
present, even if it's an empty host, must begin with a slash).  So
file:/// and file:/ and file://localhost/ all mean exactly the same thing,
whether or not they are followed by anything (which must be an absolute
file name without its leading /).  My apologies for reporting the "bug"
that did not in fact exist, but perhaps file:/// should be used anyway if
it's more compatible?

Davis


-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.