Geoffrey Young wrote:
I'm still a little curious if there are any pitfalls to having both
installed on the same machine
there shouldn't be, provided you use a recent version and don't override the
checks in Makefile.PL.
The only big gotcha I can think of would be constants if you want the sam
> I'm still a little curious if there are any pitfalls to having both
> installed on the same machine
there shouldn't be, provided you use a recent version and don't override the
checks in Makefile.PL.
--Geoff
On 10/15/05, Chris Winters <[EMAIL PROTECTED]> wrote:
> I've been scouring the MP2 docs but can't find out whether I can have
> MP1 and MP2 safely installed on the same machine. Does anything exist
> on this?
>
> Why I'm asking: I've got MP 1.29 and 2.0.2-RC2 installed, plus the
> latest libapreq2.
Matt Hahnfeld wrote:
> I was going through the filters documentation for mod_perl 2.0 here:
>
> http://perl.apache.org/docs/2.0/user/handlers/filters.html
>
> Under "All-in-one" filter, there's some source code for Dump.pm. Run
> on my system under mod_perl 2.0.0 and Apache 2.0.54, it returns t
Stas Bekman wrote:
Carl Johnstone wrote:
I'd suggest rewording the "answer" to something like:
In a URL which contains a query string, if the string has multiple
parts separated by ampersands and it contains a key named "reg", for
example http://example.com/foo.pl?foo=bar®=foobar
Hi Folks
>carl was saying that if you put a literal
>'http://example.com/foo.pl?foo=bar®=foobar' in your html _that_ is the
>cause of the problem - unescaped ampersands in url links are not allowed, so
>the literal url in user html should be
>'http://example.com/foo.pl?foo=bar®=foobar'.
Sorry,
On Tue, Apr 26, 2005 at 10:31:42AM -0400, Stas Bekman wrote:
>>> Since when unescaped & in the QUERY_STRING part of the URL are not allowed?
>> I dunno the specifics, but if you try using the w3c validator you end up
>> with something like this
>> reference not terminated by REFC delimiter
>> h
Carl Johnstone wrote:
I'd suggest rewording the "answer" to something like:
In a URL which contains a query string, if the string has multiple parts
separated by ampersands and it contains a key named "reg", for example
http://example.com/foo.pl?foo=bar®=foobar, then some browser
OK, in which case it must be some relatively recent change, since an
unescaped & in the QUERY_STRING was a valid separator. A pointer to the
relevant RFC would be nice so we can add that to the URL that started
this thread.
Here?
http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.htm
Steve Hay wrote:
Stas Bekman wrote:
Geoffrey Young wrote:
Since when unescaped & in the QUERY_STRING part of the URL are not allowed?
I dunno the specifics, but if you try using the w3c validator you end up
with something like this
reference not terminated by REFC delimiter
http://example.c
Stas Bekman wrote:
>Geoffrey Young wrote:
>
>
>>>Since when unescaped & in the QUERY_STRING part of the URL are not allowed?
>>>
>>>
>>I dunno the specifics, but if you try using the w3c validator you end up
>>with something like this
>>
>> reference not terminated by REFC delimiter
>>
>>
Geoffrey Young wrote:
Oh, I see, I thought you were talking a bug in the docs building system.
But if you write:
'http://example.com/foo.pl?foo=bar®=foobar'.
There is no problem whatsover. Since there is no ® here.
exactly :)
Since when unescaped & in the QUERY_STRING part of the URL are not
> Oh, I see, I thought you were talking a bug in the docs building system.
>
> But if you write:
>
> 'http://example.com/foo.pl?foo=bar®=foobar'.
>
> There is no problem whatsover. Since there is no ® here.
exactly :)
>
> Since when unescaped & in the QUERY_STRING part of the URL are no
Geoffrey Young wrote:
Beg your pardon? Have you looked at the HTML source code? it goes:
http://example.com/foo.pl?foo=bar®=foobar";>http://example.com/foo.pl?foo=bar®=foobar
I think what carl was saying was that the source of the bug in the
discussion was incorrect, not in how we render the
> Beg your pardon? Have you looked at the HTML source code? it goes:
>
> href="http://example.com/foo.pl?foo=bar®=foobar";>http://example.com/foo.pl?foo=bar®=foobar
I think what carl was saying was that the source of the bug in the
discussion was incorrect, not in how we render the page o
Geoffrey Young wrote:
Carl Johnstone wrote:
On:
http://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html
It talks about browsers misreading URLs like:
http://example.com/foo.pl?foo=bar®=foobar
Presuming this is within a HTML page e.g.:
http://example.com/foo.pl?foo=bar®=foobar";> .
Carl Johnstone wrote:
>
> On:
> http://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html
>
>
> It talks about browsers misreading URLs like:
>
> http://example.com/foo.pl?foo=bar®=foobar
>
> Presuming this is within a HTML page e.g.:
>
> http://example.com/foo.pl?foo=bar®=f
On Wed, 09 Jun 2004 07:09:16 -0700, Stas Bekman wrote
> Chris wrote:
> > On Wed, 09 Jun 2004 06:01:12 -0700, Stas Bekman wrote
> >
> >>Chris Shiflett wrote:
> >>
> >>Alternatively, someone may want to start a wiki project where people
> >>can dump anythings they want, and then we can merge some o
Chris wrote:
On Wed, 09 Jun 2004 06:01:12 -0700, Stas Bekman wrote
Chris Shiflett wrote:
Alternatively, someone may want to start a wiki project where people
can dump anythings they want, and then we can merge some of those
notes back into the docs.
Right then, unless someone comes up with somet
On Wed, 09 Jun 2004 06:01:12 -0700, Stas Bekman wrote
> Chris Shiflett wrote:
>
> Alternatively, someone may want to start a wiki project where people
> can dump anythings they want, and then we can merge some of those
> notes back into the docs.
Right then, unless someone comes up with somethi
Chris Shiflett wrote:
--- Stas Bekman <[EMAIL PROTECTED]> wrote:
2) docs need to have user comments.
I'm not sure it's a good idea. We already have a way too much
documentation. Instead of making it even harder for users to find
things, one should take the existing docs and improve them, rather
the
--- Stas Bekman <[EMAIL PROTECTED]> wrote:
> 2) docs need to have user comments.
>
> I'm not sure it's a good idea. We already have a way too much
> documentation. Instead of making it even harder for users to find
> things, one should take the existing docs and improve them, rather
> then dump ra
22 matches
Mail list logo