websocket-spec
  1. websocket-spec
  2. WEBSOCKET_SPEC-195

Clarify path param (URI template) matching behavior of trailing '/' in incoming path

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      As mentioned in jsr356-experts:
      http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-04/message/15

      In the email http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-03/message/33
      From: Danny Coward
      Subject: Closing the gaps in the URI matching specification
      Date: Mon, 18 Mar 2013 17:12:35 -0700

      He gives a particular example ...

      (snip)
      suppose we have three endpoints and their paths:
      endpoint A: /a/

      {var}/c
      endpoint B: /a/b/c
      endpoint C: /a/{var1}/{var2}
      incoming URI: a/b/c matches B, not A or C, because an exact match is preferred.
      incoming URI: a/d/c matches A with variable var=d, because like goldlocks, its just right
      incoming URI: a/x/y/ matches C, with var1=x, var2=y
      (/snip)

      I have issue with In the last match of incoming path "a/x/y/" (note the trailing slash)
      I feel this is a bad behavior of the matching.

      A scenario to ponder this behavioral quirk.

      endpoint A: "/a/{var}

      /c/"
      endpoint B: "/a/b/c"
      endpoint C: "/a/

      {var1}/{var2}"
      endpoint D: "/a/{var1}

      /

      {var2}

      /

      {var3}

      "

      What should the incoming path "/a/x/y/" match?
      Is it endpoint C with ...
      var1 = "x"
      var2 = "y"
      or is it endpoint D with ...
      var1 = "x"
      var2 = "y"
      var3 = ""

      I don't think it should match C as the incoming path has the trailing slash indicating another path segment.
      Since we are calling this whole concept PathParam, I feel that this would keep us consistent as well.

        Activity

        Hide
        markt_asf added a comment -

        RFC3986 essentially says it is up to us how to handle trailing /.

        I currently prefer the position that /a/b != /a/b/ and that /a/b/ does not match /a/

        {var}

        This is closely aligned with how to handle //.

        Show
        markt_asf added a comment - RFC3986 essentially says it is up to us how to handle trailing /. I currently prefer the position that /a/b != /a/b/ and that /a/b/ does not match /a/ {var} This is closely aligned with how to handle //.
        Hide
        dannycoward added a comment -

        Yes I think /a/b != /a/b/, especially because some http servers in front of the websocket impl may find the difference significant.

        Show
        dannycoward added a comment - Yes I think /a/b != /a/b/, especially because some http servers in front of the websocket impl may find the difference significant.

          People

          • Assignee:
            Unassigned
            Reporter:
            joakimerdfelt
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: