On 06/11/2015 09:48 AM, Sven Van Caekenberghe wrote:
Here is one older discussion that let to Zn going away from the better safe
than sorry approach to encoding:
http://forum.world.st/Zinc-How-to-use-the-character-in-an-URL-td4716386.html#a4716459
You have to read it up to the end.
On 11 Jun 2015, at 16:19, Jimmie Houchin <jlhouc...@gmail.com> wrote:
This is exactly why I expressly state I am not a language lawyer and explicitly
do not know what is and is not expressly forbidden or allowed with regards to a
comma.
You are correct about the Wikipedia article.
Is it every wrong or illegal to use a complete safely encoded request? Is it
just simply not required?
So not fully encoded is still valid and legal and also the fully encode is also
fully valid and legal.
Yes, any server should accept all encodings.
However, the following are different:
http://foo.com/bar?x=1
http://foo.com/bar?x%3D1
In the second case, you take away the meaning of = by encoding it. So you just
can't encode everything everywhere.
eg:
http://yourserver.com/path?options=eggs,toast,coffee
is fully valid and legal, but may encounter problems depending to whom the
request is made and their implementation?
Encoding is not required but is at the discretion of the server implementation?
http://yourserver.com/path?options=eggs%2Ctoast%2Ccoffee
is fully valid and legal and is always usable and will never encounter problems?
All valid server side implementations will handle this properly?
Since I am sure that the API that I am writing for is probably not the only
server implementation which requires the comma to be encoded.
Actually, this is the first time I hear of a problem with ,
So, from that perspective, the server might be in error.
And regardless of legality of the use of comma it appears that some implementers are on
the "to be safe we encode everything" side of things. It would be nice to have
some option which allows us to encode all to be safe option.
Yes, maybe such an option would be good, but only if it is really needed.
Thanks for listening and your help.
Jimmie
I am not a domain expert.
This my first attempt to do anything like this, so I have not
encountered it either.
However, it seems that there is a lot of ambiguity, discussion and
variety in implementations as to whether or not to encode the comma.
As ZnClient is the client and user of somebody else's provided service.
It bears the burden of being able to communicate with the server whether
the server is right or wrong. And are we actually able to say the
encoding the comma is wrong even if unencoded may be legal.
In other words can to take the counter argument, could I unambiguously
prove to someone that they must allow for unencoded commas in the query?
That would force upon them the requirement of handling both encoded and
unencoded commas in queries. The simpler implementation may be simply to
require encoded commas as this API does.
Regardless. We can't control other peoples implementations. Though we
may find ourselves in a situation to write apps which use their services.
Is this option really needed. In my opinion, yes. As we are availing
ourselves to other peoples services and implementations. And as the
requirements of the implementation isn't exactly clear.
And as can be demonstrated amply encoding commas in the URI query is the
default for Python and other web client languages and tools. So, Python,
one of the largest web tool languages encodes by default. Implementers
may often understand that as meaning it should be so. Or at least
according to one communities understanding of the specs. Or at least
their seeking to be practical in face of ambiguity.
Regarding encoding the = equal sign. The same spec says in general
don't, that it may cause problems.
I was simply seeking understanding and a solution. I have received both.
Thanks.
Jimmie
