idp RemoteUser url-parameters jsession occasional-login-failures

[Brent Putman]

On 10/9/16 3:38 AM, Rainer Hoerbe wrote:
>
>
>   https://host[:port]/path[;parameters][?query_string]
>
> Those parameters were causing login failures.
> Just for the record: RFC 3986 says:
> "The query component is indicated by the first question mark ("?") character and terminated by a number sign ("#") character or by the end of the URI.“

Yes, it does say that in the first paragraph of section 3.4.  But
that's not relevant because...

>
> Therefore the key-value pair in "[;parameters]“ is illegal.
>
> Implementations might process the semicolon as starting the query string, because it is not a "unreserved character" that may appear in the path. However, clients issuing those URLs should be flagged as misbehaving.

No, I believe you misunderstanding Jim's point, and therefore you are
misreading the spec.  These parameters are not a part of the *query*,
they are (or can be) part of each individual *path segment*.

In RFC 3986, it actually discusses them specifically.  In the very last
paragraph of section 3.3 it states:

> Aside from dot-segments in hierarchical paths, a path segment is
>    considered opaque by the generic syntax.  URI producing applications
>    often use the reserved characters allowed in a segment to delimit
>    scheme-specific or dereference-handler-specific subcomponents.  For
>    example, the semicolon (";") and equals ("=") reserved characters are
>    often used to delimit parameters and parameter values applicable to
>    that segment.  The comma (",") reserved character is often used for
>    similar purposes.  For example, one URI producer might use a segment
>    such as "name;v=1.1" to indicate a reference to version 1.1 of
>    "name", whereas another might use a segment such as "name,1.1" to
>    indicate the same.  Parameter types may be defined by scheme-specific
>    semantics, but in most cases the syntax of a parameter is specific to
>    the implementation of the URI's dereferencing algorithm.


So the URL path can look like:  /foo;x=1/bar;y=2,z=3/baz;ver=1.1.

None of that has anything to do with the query part of the URL.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161009/3952bfce/attachment.html>