Open jnvitti opened 10 months ago
jnvitti
commented
10 months ago Screenshot showing this error in Firefox, along with the full URL at the time of the error (a search results page, which is when the error usually appears). Note that when this error displays in Library Search, other Shibbolized apps are also all broken simultaneously, such as Alma & the Emory Directory.
tclayton33
commented
10 months ago @rotated8 @abelemlih - Jenny has provided more details. I know we'll be closing this ticket and writing this up differently, but for now this seems like a good place to put it.
More about when this happens: For Library Search, this mostly happens when I’ve left the page and then come back to do another search, but it sometimes happens when I’m opening my browser for the first time for the day (I suspect in those cases, the session went bad the previous day, before I closed the browser, and I didn’t notice) . The existing and previous results are cached, I guess, so when I’m returning to an existing session I can re-run the same search successfully (or in a way that seems to be successful, with the page going blank briefly and then appearing to load again) and I can navigate backwards through previous searches, but when I type a new search term and click Search, I get the Bad Request message. Then again, if I open a new tab in the same browser session and try to go to the top level page (https://search.libraries.emory.edu/), that also generates the Bad Request message, so I think it’s all just bricked once I’m in the stale session, rather than it actually being triggered by a search results page. It’s just that I’m always trying to run a new search when I first see this error, so that’s what appears to be breaking it. I usually do not log in to Library Search at work unless I’m testing or demonstrating something, so almost always I’m logged out of Library Search when this error happens – but it does happen when I’m logged in, too. I’ll also note that sometimes this error resolves itself without me clearing the cache/cookies – for example, when Firefox does a hard reset to install updates, Library Search (and Alma, etc.) almost always works when the browser relaunches, even though the cache & cookies remain. Also, sometimes I can trick the timing of things by playing Alma & other Shibbolized applications off of each other, and get the browser to let me back in to the Shibbolized applications without clearing my cookies, but I haven’t figured out exactly how that works yet, so it’s probably not helpful for troubleshooting.
tclayton33
commented
10 months ago also from Jenny: This is an ongoing problem across multiple Emory applications that has been happening multiple times a week for both staff and patrons for years (since before Library Search existed)
regarding testing: If y’all are planning to try multiple applications in your testing/troubleshooting, I suggest including the Emory Online Directory (https://directory.service.emory.edu/). It’s the only application I’ve observed breaking that I think is not Shibbolized, although it does require you to be on campus to use it.
Is your feature request related to new functionality not yet included in the product? Please describe. No -- it's a bug report.
Is your feature request related to a problem or a change to existing functionality? Please describe. Yes. When Shibboleth starts to fritz in a browser session, Library Search is usually one of the first applications to fail, even when users are not logged in to Library Search (which is especially frustrating and confusing). The error that is presented in Library Search in these instances is "400 Bad Request Bad Request Your browser sent a request that this server could not understand. Size of a request header field exceeds server limit." (This is the language from Firefox; I don't remember if the language is the same in Chrome, but it happens regularly in both browsers.) The user must then switch to a different browser, use an incognito/private browsing session, or clear all their cookies in order to perform any searches in the catalog, which should not require SSO at all -- all of this remains frustrating and confusing. I know my team and I (ILL) are especially heavy users of the catalog, but this happens to each of us at least 2-3 times every week.
Describe the solution you'd like The best solution would be to find out why Shibboleth is so finicky at Emory and causes such frequent failures across all applications (Library Search, Alma, JSTOR, and directory.service.emory.edu all fail multiple times every week -- JSTOR almost every single time it is opened -- and most other databases and Shibbolized applications fail from time to time). If we can advocate for that, that would be great. However, since other than advocacy that issue is outside of our scope, would it also be possible to edit the Library Search server to allow larger cookies and possibly reduce these errors? See, for example, https://www.ibm.com/support/pages/request-header-field-size-exceeds-limit-web-server. Any other server-related changes that would address this issue would be great -- it doesn't have to be this specific solution. Alternately, I don't know where these error messages originate, but if it's from the server (and not from the browser itself), is there a way to edit the error message to at least provide some troubleshooting or workarounds to users (clear your cache; use an incognito/private browsing session, reach out to LibAnswers if you need help, etc.)?
Describe alternatives you've considered Currently, users must either switch to a different browser, use an incognito/private browsing session, or clear all their cookies in order to perform any searches in the catalog once this error appears.
How will this impact users? This error fully stops researchers from being able to search the catalog, and it comes up frequently, at least for heavy users of Shibbolized applications at Emory. Removing this barrier will allow users to perform the most basic function of the catalog without regular interruptions.