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
==================