Shib IdP V3.2.1, Jetty 9.3.6, and HTTP/2

[David Langenberg]

I found I had to add this to alpn.ini to get older clients to behave.

## Specifies what protocol to use when negotiation fails.
jetty.alpn.defaultProtocol=http/1.1

Dave

> On Feb 2, 2016, at 5:25 PM, Tom Scavo <trscavo at gmail.com> wrote:
> 
> I'm working with a colleague at Williams College to register metadata
> for a v3.2.1 IdP deployment. Just beneath the surface of this IdP,
> there is some weirdness going on. We believe we can trace it to Jetty
> 9.3.6 but first let me provide the symptoms.
> 
> The URL that exhibits the problem is an old V2 Status URL:
> 
> https://idp.williams.edu/idp/profile/Status
> 
> Shib IdP V3.2.1 should return 404 on such a request, and for some
> browser clients (such as Chrome) that is exactly what happens. Other
> browser clients are all over the map.
> 
> Curl on my Mac produces this:
> 
> $ curl --verbose https://idp.williams.edu/idp/profile/Status
> *   Trying 137.165.4.25..
> * Connected to idp.williams.edu (137.165.4.25) port 443 (#0)
> * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> * Server certificate: idp.williams.edu
> * Server certificate: COMODO RSA Organization Validation Secure Server CA
> * Server certificate: COMODO RSA Certification Authority
> * Server certificate: AddTrust External CA Root
>> GET /idp/profile/Status HTTP/1.1
>> Host: idp.williams.edu
>> User-Agent: curl/7.43.0
>> Accept: */*
>> 
> * Connection #0 to host idp.williams.edu left intact
> invalid_preface
> 
> Other curls on other client machines produce different results but
> none of them 404.
> 
> We've googled and experimented and have come up short. Evidence is
> pointing to Jetty and its handling of HTTP/2 but we can't be sure.
> 
> Has anyone else seen anything like this? Other suggestions?
> 
> Thanks in advance,
> 
> Tom
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


--
David Langenberg
Identity & Access Management Architect
The University of Chicago