OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] RE: "+" -- %2B or not %2B!


It should be simple - just figure out which option is nobler.
 

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Computing Security Infrastructure
(206) 679-5933

 


From: Tan, William [mailto:William.Tan@neustar.biz]
Sent: Friday, July 07, 2006 11:27 PM
To: Wachob, Gabe
Cc: openxri-users@lists.sourceforge.net; xri@lists.oasis-open.org
Subject: [xri] RE: "+" -- %2B or not %2B!

I like the subject J

 

I agree that it boils down to your two options:

 

escape "+"  to "%2B" and " " to "+"  OR don't escape "+" and escape " " to %20

 

with clarification that any other octet not allowed in the query be %-encoded.

 

FWIW, I’ve updated the openxri client to send application/xrds%2Bxml. I’m not steering it in that direction.. just making the minimally required changes.

 

=wil (http://xri.net/=wil)

 

 


From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Saturday, July 08, 2006 6:33 AM
To: Tan, William
Cc: openxri-users@lists.sourceforge.net; xri@lists.oasis-open.org
Subject: "+" -- %2B or not %2B!

 

That is the question!

 

I'm not quite certain I still am adamant about the non-escaping of plus - non-escaping could be an issue which makes implementation more difficult.

 

The problem with accepting "+" (if we specify escaping) as "+" instead  of " " is that it defeats the purpose of the requirement of escaping "+" - if someone actually *wants* to put " " in a parameter, then are we telling them not to use "+"? If so, then why do we have to escape "+" (we assumed we were specifying that "+" is escaped).

 

I think we just need to be specific and unambiguous - escape "+"  to "%2B" and " " to "+"  OR don't escape "+" and escape " " to %20....

 

I'm more on the fence than ever.

 

Regardless, the openxri code doesn't work as is.... but we should probably decide on which way to move forward on this...

 

    -Gabe

 


From: openxri-users-bounces@lists.sourceforge.net [mailto:openxri-users-bounces@lists.sourceforge.net] On Behalf Of Tan, William
Sent: Friday, July 07, 2006 11:24 AM
To: Wachob, Gabe
Cc: openxri-users@lists.sourceforge.net
Subject: Re: [Openxri-users] Problem with proxy/escaping

This has prompted me to search for the reference for the reason behind HTTP clients encoding spaces as pluses in queries. Turns out that it is sort of “specified” in RFC1630:

 

Within the query string, the plus sign is reserved as shorthand
      notation for a space.  Therefore, real plus signs must be encoded.
      This method was used to make query URIs easier to pass in systems
      which did not allow spaces.

 

I agree that this is really a weird glitch and is probably one that people hate. Also, it is true that in the URI spec or elsewhere, no structure has been placed in the query component though applications have sort of stuck with the “foo=bar&baz=apple” format.

 

It’s fine with me if we do not wish to encode the plus sign. Conversely, if the plus sign was encoded, should it be recognized? More generally, should any percent encoded sequences be decoded? For example, t%65xt/uri-list should be the same as “text/uri-list”.

 

You’re right, it seem the multi-argument form URI constructor does escape ‘%’ signs.

 

Converting spaces back to ‘+’ probably would not be a problem for _xrd_r and _xrd_m since media types are not allowed to have spaces in them (I think.)

 

=wil (http://xri.net/=wil)

 

 


From: openxri-users-bounces@lists.sourceforge.net [mailto:openxri-users-bounces@lists.sourceforge.net] On Behalf Of Wachob, Gabe
Sent: Saturday, July 08, 2006 3:11 AM
To: Tan, William
Cc: openxri-users@lists.sourceforge.net
Subject: Re: [Openxri-users] Problem with proxy/escaping

 

Wil-

 

Let me first say that I think the '+' should not be escaped, no matter what the current behavior of openxri is, at least in the xri resolution parameters.

 

As for openxri code, I was only using the client code in proxy mode against a openxri proxy using the resolveAuthToXRD method.

 

I don't have the source code in front of me, but its easy to find.

 

Its in the openxri resolver client code (I think this is in Resolver.java). Look for URLEncoder escaping the string Tags.CONTENT_TYPE_XRDS. I simply removed the invocation to URLEncoder.encode()

 

In the server code, the getParameter automatically "unescapes" '+' to ' '... which is helpful if you are writing a CGI behind an HTML form, but otherwise broken, imho. My fix is simply to convert spaces back to '+'.

 

Its interesting, when I run your code, it works fine with %2B (escaped '+')...

java TestURI 'http://abc.com/%2Ber'

 

But if you run it with the following code, you see the %252B problem.... (which is what I'm seeing in the openxri code).

 

====

import java.net.URI;
import java.lang.System;

 

class test

 

{

 

public static void main(String [] argv)
{

 

        try
        {
        URI furi=new URI("http://example.com:8080/foo");

 

        URI nuri=new URI(furi.getScheme(), furi.getAuthority(), furi.getPath(), furi.getQuery(), furi.getFragment());
        System.out.println(nuri);
        URI turi= new URI("http", null, "example.com", 80, "/foo", "test=joe%2Bblah", null);
        System.out.println(turi.toString());
        }
        catch (Exception e)
        {
                e.printStackTrace();
       
        }      
}

 

}

=========

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]