multiple successive URL parameter delimiters?

I've got a few php pages that I invoke like this:

http://sample.php/?parm1=xxx&parm2=yyy&parm3=zzz

Sometimes though, I end up with this:

http://sample.php/?&parm2=yyy
^^
Although this seems to work as far as I could test it, it is maybe not
as clean as it should be.

I could add some more code to clean it up. My question is, do I have
to? Why?

Or is this kind of double delimiter (?&) considered valid and harmless?

--
Gregor mit dem Motorrad auf Reisen
http://hothaus.de/greg-tour/

Greg N. wrote:
> I've got a few php pages that I invoke like this:
>
> http://sample.php/?parm1=xxx&parm2=yyy&parm3=zzz
>
> Sometimes though, I end up with this:
>
> http://sample.php/?&parm2=yyy
> ^^
> Although this seems to work as far as I could test it, it is maybe not
> as clean as it should be.
>
> I could add some more code to clean it up. My question is, do I have
> to? Why?
>
> Or is this kind of double delimiter (?&) considered valid and
> harmless?

well even the good one is bad
http://sample.php/?parm1=xxx&parm2=yyy&parm3=zzz
should be
http://www.somedomain.com/sample.php...=yyy&parm3=zzz

(note no / before the ? and a domain before the file name)

Greg N. wrote:
> I've got a few php pages that I invoke like this:
>
> http://sample.php/?parm1=xxx&parm2=yyy&parm3=zzz
>
> Sometimes though, I end up with this:
>
> http://sample.php/?&parm2=yyy
> ^^
> Although this seems to work as far as I could test it, it is maybe not
> as clean as it should be.
>
> I could add some more code to clean it up. My question is, do I have
> to? Why?
>

Only if you want it to work correctly. This is not according to the
specs, so it's up to every browser on how to interpret it.

> Or is this kind of double delimiter (?&) considered valid and harmless?
>

No, it is not valid. And you should not have to add code to "clean it
up". You shouldn't be generating it in the first place.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

..oO(Jerry Stuckle)

>Greg N. wrote:
>> I've got a few php pages that I invoke like this:
>>
>> http://sample.php/?parm1=xxx&parm2=yyy&parm3=zzz
>>
>> Sometimes though, I end up with this:
>>
>> http://sample.php/?&parm2=yyy
>> ^^
>> Although this seems to work as far as I could test it, it is maybe not
>> as clean as it should be.
>>
>> I could add some more code to clean it up. My question is, do I have
>> to? Why?
>>
>
>Only if you want it to work correctly. This is not according to the
>specs

Which spec?

>so it's up to every browser on how to interpret it.

The query string is interpreted by the server, the browser has nothing
to do with that.

>> Or is this kind of double delimiter (?&) considered valid and harmless?
>>
>
>No, it is not valid. And you should not have to add code to "clean it
>up". You shouldn't be generating it in the first place.

It's not forbidden by the RFCs. The "?" correctly delimits the query
from the path, and the query itself is just a string. AFAIK the meaning
of the "&" inside of the query is not even defined in any RFC, it's just
common sense to use it as a separator between the parameters.

Micha

Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> Greg N. wrote:
>>> I've got a few php pages that I invoke like this:
>>>
>>> http://sample.php/?parm1=xxx&parm2=yyy&parm3=zzz
>>>
>>> Sometimes though, I end up with this:
>>>
>>> http://sample.php/?&parm2=yyy
>>> ^^
>>> Although this seems to work as far as I could test it, it is maybe not
>>> as clean as it should be.
>>>
>>> I could add some more code to clean it up. My question is, do I have
>>> to? Why?
>>>
>> Only if you want it to work correctly. This is not according to the
>> specs
>
> Which spec?
>
>> so it's up to every browser on how to interpret it.
>
> The query string is interpreted by the server, the browser has nothing
> to do with that.
>
>>> Or is this kind of double delimiter (?&) considered valid and harmless?
>>>
>> No, it is not valid. And you should not have to add code to "clean it
>> up". You shouldn't be generating it in the first place.
>
> It's not forbidden by the RFCs. The "?" correctly delimits the query
> from the path, and the query itself is just a string. AFAIK the meaning
> of the "&" inside of the query is not even defined in any RFC, it's just
> common sense to use it as a separator between the parameters.
>
> Micha
>

I'd have to look up the RFC's, but it's too late tonight.

But basically, '?' is defined as the separator between the URI and the
query string. '&' is defined as the separator between query parameters.
It is invalid immediately following the '?' because there is no
parameter preceding it.

It may work in the current release the op is using, but I wouldn't
guarantee it to work in all releases.

But you're right - it isn't interpreted by the browser - my mistake.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================