[ 
https://issues.apache.org/jira/browse/YARN-5167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15314486#comment-15314486
 ] 

Varun Saxena edited comment on YARN-5167 at 6/3/16 5:56 PM:
------------------------------------------------------------

What I was thinking was that we will encode % once. That is sanitize the 
incoming string. 
And then apply other separators. 
I wasn't thinking of applying it automatically inside the encode methods. 
However, till we repeat the same sequence in reverse as we used while encoding, 
that should work as well.  Will need to try out few examples though. It will 
however be unnecessary to encode % multiple times.

Cant we just document how to use it and the intention of it ? Just document 
that if you expect encoded values in your incoming strings, encode % as well.

After all, the sequence of separators used while encoding and decoding has to 
be taken care by the user of Separator enum anyways. Maybe users of this enum 
can take care of encoding % as well, if they expect the same sequence of 
characters as the characters encountered after encoding other separators. 
We just provide them a mechanism to encode % as well by adding it in the 
Separator enum.


was (Author: varun_saxena):
What I meant was that we will encode % once. That is sanitize the incoming 
string. 
And then apply other separators. 
I wasn't thinking of applying it automatically inside the encode methods. 
However, till we repeat the same sequence in reverse as we used while encoding, 
that should work as well.  Will need to try out few examples though. It will 
however be unnecessary to encode % multiple times.

Cant we just document how to use it and the intention of it ? Just document 
that if you expect encoded values in your incoming strings, encode % as well.

After all, the sequence of separators used while encoding and decoding has to 
be taken care by the user of Separator enum anyways. Maybe users of this enum 
can take care of encoding % as well, if they expect the same sequence of 
characters as the characters encountered after encoding other separators. 
We just provide them a mechanism to encode % as well by adding it in the 
Separator enum.

> Escaping occurences of encodedValues
> ------------------------------------
>
>                 Key: YARN-5167
>                 URL: https://issues.apache.org/jira/browse/YARN-5167
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Joep Rottinghuis
>            Assignee: Sangjin Lee
>            Priority: Critical
>              Labels: yarn-2928-1st-milestone
>
> We had earlier decided to punt on this, but in discussing YARN-5109 we 
> thought it would be best to just be safe rather than sorry later on.
> Encoded sequences can occur in the original string, especially in case of 
> "foreign key" if we decide to have lookups.
> For example, space is encoded as %2$.
> Encoding "String with %2$ in it" would decode to "String with   in it".
> We though we should first escape existing occurrences of encoded strings by 
> prefixing a backslash (even if there is already a backslash that should be 
> ok). Then we should replace all unencoded strings.
> On the way out, we should replace all occurrences of our encoded string to 
> the original except when it is prefixed by an escape character. Lastly we 
> should strip off the one additional backslash in front of each remaining 
> (escaped) sequence.
> If we add the following entry to TestSeparator#testEncodeDecode() that 
> demonstrates what this jira should accomplish:
> {code}
>     testEncodeDecode("Double-escape %2$ and %3$ or \\%2$ or \\%3$, nor  
> \\\\%2$ = no problem!", Separator.QUALIFIERS,
>         Separator.VALUES, Separator.SPACE, Separator.TAB);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org

Reply via email to