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...
You have to read it up to the end.
On 11 Jun 2015, at 16:19, Jimmie Houchin <jlhouchin@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:
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