Openurls generated could by Alma/Primo be shorted by:

1. Not sending duplicate parameters.
2. Not sending empty parameters.

Background:

We have noticed that OpenURLs produced by Alma/Primo (which are then sent on to our ILLiad server, which can require redirection to get the patron authenticated) can be VERY long. So long in fact, that they can produce errors for our ILLiad web server. The ILLiad server will end up reporting "Request header is too large", and the user is left with a HTTP Status 400 Bad request error.

We believe the responsibility here is on the Alma/PRimo side as the urls generated could be shorted by:

1. Not sending duplicate parameters.
2. Not sending empty parameters.

Note: For our (UW-Madison's) locally developed discovery interface, we generate our own OpenURL links for things like "Request a copy" from article searching and the catalog records, so we can ensure proper length limits.

ExLibris generates OpenURL links in their UResolver (Find it) and Primo Search API

Alma/Primo OpenURLs

For example, following a "Find it at UW-Madison" link from Google Scholar and then doing "Request a copy" (sending the OpenURL on to our ILLiad server):

Starting in Google Sholar, and ending up here:
https://uwi-primoalma-prod.hosted.exlibrisgroup.com/primo-explore/openurl?sid=google&auinit=PM&aulast=Vitousek&atitle=Beyond%20global%20warming:%20ecology%20and%20global%20change&id=doi:10.2307%2F1941591&title=Ecology.&volume=75&issue=7&date=1994&spage=1861&issn=0012-9658&vid=WISC&institution=WISC&url_ctx_val=&url_ctx_fmt=null&isSerivcesPage=true

Provides an OpenURL link (request a copy) of:

https://madison.hosts.atlas-sys.com/illiad/OpenURL?Action=10&Form=30&rft.genre=article&rft.title=Ecology.&rft.stitle=Ecology.&rft.atitle=Beyond+global+warming%3A+ecology+and+global+change&rft.jtitle=Ecology.&rft.au=&rft.date=1994&rft.month=&rft.volume=75&rft.issue=7&rft.number=&rft.spage=1861&rft.epage=&rft.edition=&rft.issn=0012-9658&rft.eissn=1939-9170&rft.aulast=Vitousek&rft.aufirst=&rft.auinit=PM&rft.pub=Brooklyn+Botanical+Garden&rft.pubdate=1920-&rft.pubyear=&rft.publisher=Brooklyn+Botanical+Garden&rft.place=Brooklyn%2C+NY+%3A&rft.doi=10.2307%2F1941591&rfe_dat=35698209&rfr_id=google

Where the following parameters are included, yet blank:

au, month, number, epage, edition, aufirst, pubyear

Primo Search API

In order to display electronic availability for articles we have to query the OpenURL resolver in alma to get data back. The string we use to query the resolver is provided to us by the Primo Search API

Primo API Docs - Ex Libris Developer Network

This one is by far the biggest offender, as that API returns the "GetIt1" URL we need to use. An example URL returned to us looks like:

https://na02.alma.exlibrisgroup.com/view/uresolver/01UWI_MAD/openurl?svc_dat=CTO&ctx_enc=info:ofi/enc:UTF-8&ctx_id=10_1&ctx_tim=2020-02-07T10%3A04%3A19IST&ctx_ver=Z39.88-2004&url_ctx_fmt=info:ofifmt:kev:mtx:ctx&url_ver=Z39.88-2004&rfr_id=info:sidprimo.exlibrisgroup.com-proquest&req_id=&rft_val_fmt=info:ofifmt:kev:mtx:journal&rft.genre=article&rft.atitle=Telltale%20warming%20likely%20to%20hit%20poorer%20countries%20first&rft.jtitle=Nature&rft.btitle=&rft.aulast=Schiermeier&rft.auinit=&rft.auinit1=&rft.auinitm=&rft.ausuffix=&rft.au=Schiermeier,%20Quirin&rft.aucorp=&rft.date=2018-04-26&rft.volume=556&rft.issue=7702&rft.part=&rft.quarter=&rft.ssn=&rft.spage=415&rft.epage=416&rft.pages=415-416&rft.artnum=&rft.issn=00280836&rft.eissn=14764687&rft.isbn=&rft.sici=&rft.coden=&rft_id=info:doi/10.1038d41586-018-04854-2&rft.object_id=&rft.eisbn=&rft.edition=&rft.pub=Nature%20Publishing%20Group&rft.place=London&rft.series=&rft.stitle=&rft.bici=&rft_id=info:bibcode&rft_id=info:hdl&rft_id=info:lccn&rft_id=info:oclcnum&rft_id=info:pmid&rft_id=info:eric((addataeric}}&rft_dat=%3Cproquest%3E2056433252%3Cproquest%3E%3Curl%3Ehttp:search.proquest.com/docview/2056433252/%3C/url%3E,language=eng,view=MD&svc_dat=viewit&req.skin=MADskin&rft_pqid=2056433252&rft_galeid=572639507&rft_cupid=&rft_eruid=&rft_nurid=&rft_ingid=

Previously we ran this URL through a parser to validate it and then remove empty parameters. There are three issues with this data - 1) sometimes keys are duplicated, which goes against best practices 2) Data is not properly url encoded 3) There are a lot of empty parameters.

Removing those parameters for this example request would drop the length of the URL from 1328 to 1052 characters

Note: We no longer parse this data as it was dropping the duplicated parameters causing lookup issues, so it's passed through to our OpenURL resolver as we receive it from the API (aside from prepending a parameter to return XML instead of HTML)