intermittently failure to send cookies with css requests

tomhodder
(fyi: I am running the github master SOURCE) error report #1379122905

Every so often while browsing through some proxy loaded resource, the page will go all screwy, and inspection with firebug indicates that all the css files failed to load because they had been kicked to a html login page.

Further inspection using the har examiner tool indicates that no cookie was sent with the css request, explaining the problem:

https://dl.dropbox.com/u/4171924/Screenshot-07062012-09:08:31PM.png

Restarting firefox usually makes the problem go away, and its not limited to one particular site, as I have seen this behaviour on the open.ac.uk library search page and also on the wiley page as referenced in the screenshot above.
  • dstillman
    Simon will have to comment on this, but I don't think that's the problem. The CSS file comes from a different domain and doesn't require a login: http://onlinelibrarystatic.wiley.com/css/importAll.css

    The issue seems to be that it's being requested via the proxy unnecessarily. You might be able to work around it by deleting that domain from Zotero's proxy preferences.
  • tomhodder
    edited July 6, 2012
    Sure, I noticed that difference. However if you inspect the working version of the same request (after a restart, and relogin) the css request is associated with a cookie header;



    https://dl.dropbox.com/u/4171924/Screenshot-07062012-09:51:53PM.png
  • tomhodder
    edited July 6, 2012
    But your comment suggests that a work-around would be to exclude the wiley static content URL from the proxy. However once this effect is happening, I see in various search portals the same behaviour.

    I can see from watching the request in chrome network tool, that the libezproxy.open.ac.uk proxy is replacing the links to the css files to proxified ones;
    http://onlinelibrarystatic.wiley.com.libezproxy.open.ac.uk/css/importAll.css

    and those requests are going to require authentication, because bare requests are bounced to the login html;

    $ wget --server-response -q -O/dev/null http://onlinelibrarystatic.wiley.com.libezproxy.open.ac.uk/css/importAll.css
    HTTP/1.1 302 Moved temporarily
    Date: Fri, 06 Jul 2012 21:01:16 GMT
    Server: EZproxy
    Expires: Mon, 02 Aug 1999 00:00:00 GMT
    Last-Modified: Fri, 06 Jul 2012 21:01:16 GMT
    Cache-Control: no-store, no-cache, must-revalidate
    Cache-Control: post-check=0, pre-check=0
    Pragma: no-cache
    Location: http://libezproxy.open.ac.uk/login?url=http://onlinelibrarystatic.wiley.com/css/importAll.css




    If its not something obvious then next time it kicks in, I will run a venkman session and step through the code that selects for the cookie or not...
  • tomhodder
    edited July 6, 2012
    oops, sorry I didn't read you comment through to the end.

    I suspect this might be a problem with the open.ac.uk proxy itself.
  • Simon
    When creating snapshots with the connectors and Zotero Standalone, we don't send cookies for domains other than the domain of the page being translated. Until recently, Chrome didn't provide an API to explicitly access cookies, so there was no way to retrieve cookies for other domains, and sending the same cookies to all domains is insecure. Newer versions of Chrome do provide such an API, but we haven't yet updated the Chrome connector to take advantage of this.
  • Simon
    Oops, sorry, I missed that this wasn't happening with Zotero Standalone. If that's the case, this is not something we can fix. Our CSS requests through Firefox get the same credentials as any other CSS request through Firefox.
  • tomhodder
    sorry if I confused things by mentioning chrome, this issue is occurring in the current github master checkout installed into firefox 13.0 on linux x86_64.

    It think is something to do with the university proxy behaviour, because the steps are;

    1) request to http://onlinelibrary.wiley.com.libezproxy.open.ac.uk/doi/10.1002/cmdc.v7.7/issuetoc

    2) css links in response are translated by libezproxy.open.ac.uk to;
    http://onlinelibrarystatic.wiley.com.libezproxy.open.ac.uk/css/print.css

    3) the proxy sets some cookies like so;
    https://dl.dropbox.com/u/4171924/Screenshot - 07062012 - 10:17:16 PM.png

    4) if the ".open.ac.uk" domain cookies are missing the request gets bounced to the html login page


    So I am guess that either
    1. they were never set
    2. that firefox discarded them
    3. that zotero chose to not include them in the proxied request.
Sign In or Register to comment.