Re: Generated javascript from .pl files
- From: Thomas 'PointedEars' Lahn <PointedEars@xxxxxx>
- Date: Thu, 09 Aug 2007 00:02:36 +0200
(For brevity and appreciation of the potential reader, I am leaving out
everything now that is not related to the problem at hand.)
Bart Van der Donck wrote:
Thomas 'PointedEars' Lahn wrote:
Bart Van der Donck wrote:
Thomas 'PointedEars' Lahn wrote:Doesn't apply here.
Bart Van der Donck wrote:[...]
For the OP's question, I would still councel to useThat would impose an unnecessary restriction, where
AddHandler cgi-script .js
in a specific directory holding his perl-generated javascript files.
AddHandler cgi-script .pl
Options +MultiView
would not. So in what way would the former be better, please?
4. Because web servers might use a different HTTP specification than
the visiting browser, so possible HTTP version conflicts arise.
Yes it does - it applies anywhere. The web server might use HTTP/1.1
and the browser HTTP/1.0.
First, there can be no HTTP communication that uses two different versions
of HTTP. Either both the client and the server support HTTP/1.1 or it's
going to be HTTP/1.0 in both directions (HTTP/0.9 being unlikely on the Web;
I'd like to see an otherwise usable Web client that does not support
HTTP/1.1 yet, BTW.)
Second, the possible problem of different HTTP version support does *not*
apply here. Content Negotation was not introduced with HTTP/1.1, nor is
HTTP/1.1 an absolute requirement of it. CN has many different aspects. The
one that is used here does not rely on the (Content-* request) HTTP headers.
If you have only one file with prefix `foo.js' it does not matter what HTTP
version the client supports. As long as CN is supported and enabled on the
server, it "knows" that it should pick foo.js.pl (and pass it to the CGI
module) if the request says `foo.js'.
5. Because you're *fully* browser-independent. Multiviews rely onDoesn't apply here.
browser information and the preferred order of the file extensions
they request. Browsers have errors in that regard.
It certainly does. The weakness is fundamental: your solution depends
on browser information (1) [...]
Same here. I am beginning to get the impression that you do not really know
what you are talking about. BTDT, WFM.
I could at most live with a statement that Wikipedia isn't always as
reputable;
My bad, they do explain their statement, and the explanation is sound.
Unfortunately, you had not posted it:
| Internet Explorer does not fully support HTTP/1.1 content negotiation,
| because the browser does not specify, in its requests, what character
| encodings it can accept.
The accepted character encoding is *completely irrelevant* here.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
.
- Follow-Ups:
- Re: Generated javascript from .pl files
- From: Bart Van der Donck
- Re: Generated javascript from .pl files
- References:
- Generated javascript from .pl files
- From: TonyV
- Re: Generated javascript from .pl files
- From: TonyV
- Re: Generated javascript from .pl files
- From: Thomas 'PointedEars' Lahn
- Re: Generated javascript from .pl files
- From: Bart Van der Donck
- Re: Generated javascript from .pl files
- From: Thomas 'PointedEars' Lahn
- Re: Generated javascript from .pl files
- From: Bart Van der Donck
- Re: Generated javascript from .pl files
- From: Thomas 'PointedEars' Lahn
- Re: Generated javascript from .pl files
- From: Bart Van der Donck
- Re: Generated javascript from .pl files
- From: Thomas 'PointedEars' Lahn
- Re: Generated javascript from .pl files
- From: Bart Van der Donck
- Generated javascript from .pl files
- Prev by Date: Re: Simulate Mouse Event
- Next by Date: Re: Simulate Mouse Event
- Previous by thread: Re: Generated javascript from .pl files
- Next by thread: Re: Generated javascript from .pl files
- Index(es):
Relevant Pages
|