[
https://issues.apache.org/jira/browse/THRIFT-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Steshenko reopened THRIFT-2285:
-----------------------------------------
I'm re-opening this issue to get some attention. Please close it again, if it's
not important enough or I'm breaking some workflow with this.
The change done to PHP's library doesn't do anything: the variable
{{$ESCAPE_CHARS}} is not used anywhere. Instead json_encode and json_decode
built-in functions are used.
Now JAVA can understand PHP and this is good enough for now, but ideally, the
JSON should be the same whatever language's library has generated it.
> TJsonProtocol implementation for Java doesn't allow a slash (/) to be escaped
> (\/)
> ----------------------------------------------------------------------------------
>
> Key: THRIFT-2285
> URL: https://issues.apache.org/jira/browse/THRIFT-2285
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library, JavaME - Library, PHP - Library
> Reporter: Alexander Steshenko
> Assignee: Jens Geyer
> Fix For: 0.9.2
>
> Attachments:
> THRIFT-2285_JSON_forward_slash_solidus_decoding_java-javame-php.patch
>
>
> We have PHP frontend and Java backend. Thrift is used for interaction between
> the two, entities are serialized and deserialized using TJsonProtocol.
> Whenever a string in a thrift entity contains a slash "/", PHP's
> implementation, that uses {{json_encode}} under the hood, escapes it:
> "Translation eng/rus" => "Translation eng\/rus". So the payload may look like
> this:
> {noformat}
> {"1":{"str":"Translation rus\/eng"}}
> {noformat}
> (assuming that the entity only has this one string property)
> Java cannot handle this input and fails with:
> org.apache.thrift.protocol.TProtocolException: Expected control char
> Java does not allow a slash to be escaped.
> Thrift version is 0.9.1
> Any advice on what to do for a temporary solution? Should we fix Java side or
> PHP side?
> As per json.org, a slash CAN be escaped. To me it looks more like Java is not
> standard compliant in this case. At the same time, however, I don't like the
> ambiguity of the standard allowing both unescaped and escaped slash.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
