Uploaded image for project: 'Wicket'
  1. Wicket
  2. WICKET-4442

UrlEncoder does not encode colons in path segments

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Duplicate
    • Affects Version/s: 1.5.4
    • Fix Version/s: None
    • Component/s: wicket
    • Labels:
      None

      Description

      UrlEncoder adds the colon (":") to its "dontNeedEncoding" set. This breaks redirect for stateful mounts with colons in path segments, and appears to contradict the rules in the preceding comment. Moving the exception to only apply to query parameters may be more appropriate.

        Issue Links

          Activity

          Hide
          svenmeier Sven Meier added a comment -

          On " abc:def" Wicket redirects to "abc:def?0" to add the page id, but the request doesn't even seem to arrive at my Jetty server?

          Show
          svenmeier Sven Meier added a comment - On " abc:def" Wicket redirects to "abc:def?0" to add the page id, but the request doesn't even seem to arrive at my Jetty server?
          Hide
          dretzlaff Dan Retzlaff added a comment -

          Thanks for pointing me to the RFC: http://tools.ietf.org/html/rfc3986. From section 3.3: In addition, a URI reference (Section 4.1) may be a relative-path reference, in which case the first path segment cannot contain a colon (":") character.

          In this failing case, the redirect is relative-path to "abc:def" which indeed contains a colon. If I mount the page as "mount/$

          {s}

          /extra" it works.

          When I sniff the TCP traffic, I see the 302 getting back to the browser but the browser ignoring it. Tested with Chrome and IE.

          Show
          dretzlaff Dan Retzlaff added a comment - Thanks for pointing me to the RFC: http://tools.ietf.org/html/rfc3986 . From section 3.3: In addition, a URI reference (Section 4.1) may be a relative-path reference, in which case the first path segment cannot contain a colon (":") character. In this failing case, the redirect is relative-path to "abc:def" which indeed contains a colon. If I mount the page as "mount/$ {s} /extra" it works. When I sniff the TCP traffic, I see the 302 getting back to the browser but the browser ignoring it. Tested with Chrome and IE.
          Hide
          svenmeier Sven Meier added a comment -

          Good catch, you always have to wonder what they squeeze into these RFCs .

          4.2 has a good explanation:

          A path segment that contains a colon character (e.g., "this:that")
          cannot be used as the first segment of a relative-path reference, as
          it would be mistaken for a scheme name. Such a segment must be
          preceded by a dot-segment (e.g., "./this:that") to make a relative-
          path reference.

          We could change relative urls to always start with "./", we'll have to investigate whether this breaks something.

          Show
          svenmeier Sven Meier added a comment - Good catch, you always have to wonder what they squeeze into these RFCs . 4.2 has a good explanation: A path segment that contains a colon character (e.g., "this:that") cannot be used as the first segment of a relative-path reference, as it would be mistaken for a scheme name. Such a segment must be preceded by a dot-segment (e.g., "./this:that") to make a relative- path reference. We could change relative urls to always start with "./", we'll have to investigate whether this breaks something.
          Hide
          svenmeier Sven Meier added a comment -

          rendering of relative urls

          Show
          svenmeier Sven Meier added a comment - rendering of relative urls
          Hide
          svenmeier Sven Meier added a comment -

          rendering of relative urls

          Show
          svenmeier Sven Meier added a comment - rendering of relative urls
          Hide
          mgrigorov Martin Grigorov added a comment -

          Duplicate of WICKET-4260.

          Show
          mgrigorov Martin Grigorov added a comment - Duplicate of WICKET-4260 .

            People

            • Assignee:
              Unassigned
              Reporter:
              dretzlaff Dan Retzlaff
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development