Problems with slash (/) and plus (+) in URL

Splash Forums PrettyFaces Users Problems with slash (/) and plus (+) in URL

This topic contains 6 replies, has 3 voices, and was last updated by  Christian Kaltepoth 6 years, 8 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #17870

    Ralf Haller
    Participant

    Hi,

    first of all I want to thank the authors of pretty faces for this great piece of software. It helped me solve the big problem of making JSF search engine friendly.

    Two minor problems however still exist. Within my restfull path I need to include segments that contain a slash (/) and plus (+) characters. These characters are part of the segment names and can’t be omitted.

    The links are rendered using pretty:link, here is an example:

    <pretty:link mappingId=”catalog${fn:length(node.path)}”>

    <f:param value=”#{node.path}” />

    <h:outputText value=”#{node.name}” />

    </pretty:link>

    The slashes are rendered as %2F which is correct. Plus characters however are not rendered as %2B but as space characters. Why the difference?

    When the URLs are parsed the encoded slashes are treated as “normal” slashes and segments containing %2F are split up into separate segments, i.e. /a/b%2Fc becomes /a/b/c. is there a way to prevent this from happening?

    The pretty-config,xml I use looks like this:

    <url-mapping id=”catalog2″>

    <pattern value=”/catalog/#{path0:navigationController.path0}/#{path1:navigationController.path1}” />

    <view-id>/catalog.jsf</view-id>

    <action>#{shopcontroller.catalogController.showCatalog}</action>

    </url-mapping>

    <url-mapping id=”catalog3″>

    <pattern

    value=”/catalog/#{path0:navigationController.path0}/#{path1:navigationController.path1}/#{path2:navigationController.path2}” />

    <view-id>/catalog.jsf</view-id>

    <action>#{shopcontroller.catalogController.showCatalog}</action>

    </url-mapping>

    Thanks for an help.

    Ralf

    #20674

    Plus signs are a special character in URLs used to represent spaces – I doubt you will be able to actually use a plus-sign unless you manually encode it first yourself (even that may not work.) It would be interesting if you could look in to this and figure out if PrettyFaces is doing something wrong, or if it’s a case that we *could* support – I don’t think we’ll be able to, but that’s just a guess.

    In order to accept / as a value when mapping URLs, you’ll need to us a custom regex pattern in your path parameter:

    <url-mapping id="catalog">
    <pattern value="/catalog/#{ /.*/ path:navigationController.path}" />
    <view-id>/catalog.jsf</view-id>
    <action>#{shopcontroller.catalogController.showCatalog}</action>
    </url-mapping>

    This should do what you want, and capture all path segments into a single parameter. This is described in more detail in the docs: http://ocpsoft.com/docs/prettyfaces/3.2.0/en-US/html/Configuration.html#config.pathparams.regex

    Hope this helps,

    Lincoln

    #20675

    Ralf Haller
    Participant

    I know about this possibility, but it does not solve my problems. The slashes within the path segments are decoded already, so that I can’t distinguish between slashes for splitting the path into segments and slashes contained in the path segment’s name.

    The url is always decoded prior to setting the attributes in my bean. It would be nice to disable the decoding in the path mapping.

    When using pretty:link the plus signs however are not encoded, i.e. path1=”a”, path2=”b + / c” is rendered as “a/b+++%2F+c”

    #20676

    I know about this possibility, but it does not solve my problems. The slashes within the path segments are decoded already, so that I can’t distinguish between slashes for splitting the path into segments and slashes contained in the path segment’s name.

    The problem with this is that the encoded and the decoded form of a character (for example / and %2F) in fact represent the same character from the URL perspective. I also think that some browser may try to convert the %2F into a / before sending the request to the server (because both represent the same character and / is a more common form) which will break your links.

    The url is always decoded prior to setting the attributes in my bean. It would be nice to disable the decoding in the path mapping.

    This might work. But I’m not sure if this parameter would be useful in any other case than yours.

    @lincoln: What do you think. I think it won’t do any harm to add something like this.

    When using pretty:link the plus signs however are not encoded, i.e. path1=”a”, path2=”b + / c” is rendered as “a/b+++%2F+c”

    I think that the plus sign is the correct encoding for a space character in URLs. But I might we wrong. So this would be intended behavior.

    However, I think if there are slash and plus characters in the segment names it would be the best solution to manually escape them somehow. For example use _ instead of the space when creating a URL and do it the other way around after the value has been injected into your bean. This way you won’t get into any trouble.

    #20677

    The problem here is that the actual ‘+’ is not being encoded as ‘%2B’, and I believe this is a fault of the URLEncode object, which is not actually meant to encode URLs apparently… great name, Sun.

    I agree with Christian, though. As a temporary workaround, I would manually encode the ‘+’.

    #20678

    Ralf Haller
    Participant

    The problem here is that the actual ‘+’ is not being encoded as ‘%2B’, and I believe this is a fault of the URLEncode object, which is not actually meant to encode URLs apparently… great name, Sun.

    Strange, running “URLEncoder.encode(“a + b”)” gives me “a+%2B+b” under Sun Java6

    I agree with Christian, though. As a temporary workaround, I would manually encode the ‘+’.

    This is good as a temporary hack, however a final solution would be great.

    #20679

    This is good as a temporary hack, however a final solution would be great.

    We hope to resolve this issue after we don’t use URLEncoder anymore as it isn’t meant for URL encoding. You can watch this issue to keep up with the progress of fixing this.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

Comments are closed.