chicken-janitors
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-janitors] #1019: Different uri-common results for a hairy c


From: Chicken Trac
Subject: Re: [Chicken-janitors] #1019: Different uri-common results for a hairy case
Date: Mon, 24 Jun 2013 18:40:05 -0000

#1019: Different uri-common results for a hairy case
--------------------------------+-------------------------------------------
  Reporter:  mario              |       Owner:  sjamaan   
      Type:  defect             |      Status:  closed    
  Priority:  not urgent at all  |   Milestone:  someday   
 Component:  extensions         |     Version:  4.8.x     
Resolution:  invalid            |    Keywords:  uri-common
--------------------------------+-------------------------------------------
Changes (by sjamaan):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 According to RFC3986, a path cannot contain a questionmark (which this
 blog post seems to suggest is allowed within the value part of the path
 parameter).

 Quoting the relevant parts of the BNF:

 {{{
 URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

    hier-part     = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty

    path          = path-abempty    ; begins with "/" or is empty
                  / path-absolute   ; begins with "/" but not "//"
                  / path-noscheme   ; begins with a non-colon segment
                  / path-rootless   ; begins with a segment
                  / path-empty      ; zero characters

    path-abempty  = *( "/" segment )
    path-absolute = "/" [ segment-nz *( "/" segment ) ]
    path-noscheme = segment-nz-nc *( "/" segment )
    path-rootless = segment-nz *( "/" segment )
    path-empty    = 0<pchar>

    segment       = *pchar
    segment-nz    = 1*pchar
    segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                  ; non-zero-length segment without any colon ":"

    pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

    unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
    reserved      = gen-delims / sub-delims
    gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"
    sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="
 }}}

 As you can see, the question mark occurs in {{{gen-delims}}}, which itself
 is a production of {{{reserved}}}. However, neither of these two
 productions can be derived through any of the path productions.

 As I understand it, that means that the generalised URI syntax doesn't
 allow unencoded question marks in paths, which means the example is
 incorrectly split up.  Section 3.3 ("Path") even explicitly says:
   The path is terminated by the first question mark ("?") or number sign
 ("#") character, or by the end of the URI.
 Perhaps question marks were allowed in URLs by one of the older specs?

 Also, there seems to be no formal spec that defines the "path matrix"
 stuff, only some notes from w3c with the status "personal worldview", and
 a mention that this isn't implemented and never may be implemented in
 practice ("this is not a feature of the web, but it could have been").
 Anyway, this is a separate issue from the syntax of what's allowed in a
 path string. The generic URI syntax just defines the path as a
 hierarchical sequence of opaque strings, which it also does for queries.

 The uri-common egg *might* do something with this, like it does with the
 query. On the one hand this would make it slightly more powerful (as in
 the Yahoo RESTful API), but I'm not sure the added annoyance of working
 with paths would be worth it. So few libraries even support this
 separation that Yahoo was forced to allow query arguments as an
 alternative, if I understand the docs correctly.

-- 
Ticket URL: <http://bugs.call-cc.org/ticket/1019#comment:1>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]