[cas-user] UC Davis ISAPI Client - Chrome - ERR_RESPONSE_HEADERS_TRUNCATED

1,438 views
Skip to first unread message

Ourada, John

unread,
Oct 29, 2013, 1:02:12 PM10/29/13
to cas-...@lists.jasig.org

We are using Atlas Systems Ares product with our Library.

 

They only support an ISAPI filter for authentication.

 

We found the UC Davis ISAPI client to meet theirs and our needs. 

(https://confluence.ucdavis.edu/confluence/display/IETP/CAS+ISAPI+Client)

 

Starting last Spring following a Chrome update we now get an error from

Chrome: ERR_RESPONSE_HEADERS_TRUNCATED

 

I tried to use Fiddler to see what was happening and it claims that the server is indeed returning buggy headers.

 

I have tried several times to contact the UC Davis IT support and have not heard anything back from them.  I called and sent a detailed e-mail.

 

This is only affecting Chrome, but using Fiddler, it seems that there is truly something wrong with the way that the http headers are returned.

 

To see this go to https://depaul.ares.atlas-sys.com/ares/ares.dll.

 

I see that Adam Causey reported the same issue on 9/26/2013 on gmane.org

 

-John

DePaul University

 

 

-- 
You are currently subscribed to cas-...@lists.jasig.org as: jasig-cas-user...@googlegroups.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Tom Poage

unread,
Oct 29, 2013, 6:09:30 PM10/29/13
to cas-...@lists.jasig.org
UC Davis is aware of the issue. A recent change in Chrome code uncovered
what looks to be an implementation bug in the ISAPI filter: the HTTP
protocol requires an empty line tailing the headers and the filter
apparently does not send one. Earlier Chrome code and other browsers
seem to be more forgiving of this; the new Chrome code enforces the
empty line, otherwise throwing the truncation error.

Cf. revision 202927 in
http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_stream_parser.cc?view=log#revHEAD

I'm not a Windows developer, so am trying to come up to speed on the
APIs to see what could be done with it. I have been in communication
with the original developer who suggested, if at all possible, using the
.NET CAS client.

Tom.

On 10/29/2013 10:02 AM, Ourada, John wrote:
> We are using Atlas Systems Ares product with our Library.
>
> They only support an ISAPI filter for authentication.
>
> We found the UC Davis ISAPI client to meet theirs and our needs.
>
> (*https://confluence.ucdavis.edu/confluence/display/IETP/CAS+ISAPI+Client*)
>
> Starting last Spring following a Chrome update we now get an error from
>
> Chrome: ERR_RESPONSE_HEADERS_TRUNCATED
>
> I tried to use Fiddler to see what was happening and it claims that the
> server is indeed returning buggy headers.
>
> I have tried several times to contact the UC Davis IT support and have
> not heard anything back from them. I called and sent a detailed e-mail.
>
> This is only affecting Chrome, but using Fiddler, it seems that there is
> truly something wrong with the way that the http headers are returned.
>
> To see this go to https://depaul.ares.atlas-sys.com/ares/ares.dll.
>
> I see that Adam Causey reported the same issue on 9/26/2013 on gmane.org
>
> -John
>
> DePaul University
>
> --
> You are currently subscribed to cas-...@lists.jasig.org as: tfp...@ucdavis.edu

Ourada, John

unread,
Oct 29, 2013, 9:03:46 PM10/29/13
to cas-...@lists.jasig.org
Thanks Tom!

I would like to use the .nat client, but this vendor uses an isapi filrer to provide sso with their customers.

We are very appreciative to have access to this client. As long as we know that something is or isn't happening. My internal clients are getting edgy with me and their is nothing that I can do.

If want assistance, I would be happy to try.

-John

Sent from Moxier Mail
(http://www.moxier.com)
You are currently subscribed to cas-...@lists.jasig.org as: jou...@depaul.edu

Marvin S. Addison

unread,
Oct 30, 2013, 9:17:40 AM10/30/13
to cas-...@lists.jasig.org
> UC Davis is aware of the issue. A recent change in Chrome code uncovered
> what looks to be an implementation bug in the ISAPI filter: the HTTP
> protocol requires an empty line tailing the headers and the filter
> apparently does not send one. Earlier Chrome code and other browsers
> seem to be more forgiving of this; the new Chrome code enforces the
> empty line, otherwise throwing the truncation error.

That sounds to me like the fix is a trivial one character patch. I have
a Windows development environment where I'd be willing to patch and
rebuild if you can share the source.

M
Reply all
Reply to author
Forward
0 new messages