This was enough to get it working for me:
AllowEncodedSlashes On


On Wed, Aug 28, 2013 at 12:15 PM, Joe Atzberger <joe@booksite.com> wrote:
Yeah, I hate to even see "double url-encode" suggested as the solution for *anything*.


On Wed, Aug 28, 2013 at 8:34 AM, Demian Katz <demian.katz@villanova.edu> wrote:

We have an open JIRA ticket about this issue:

 

http://vufind.org/jira/browse/VUFIND-513

 

As already discussed on-list, it has to do with Apache behavior.

 

A variation of the solution in the 27/Jul/12 comment on the ticket might work for you.  Since that comment refers to 1.x, I’ve also added a 2.x-specific comment with some updated ideas.

 

This remains a very irritating problem – I’d love to find a solution that actually “just works” without requiring hacky workarounds.  This is one of the few areas where I’m really not pleased with Apache.

 

- Demian

 

From: Joe Atzberger [mailto:joe@booksite.com]
Sent: Tuesday, August 27, 2013 11:21 PM
To: vufind-tech Tech
Subject: [VuFind-Tech] Identifiers with punctuation (Hathi) break routing

 

I loaded up a separate Solr core with Hathi ebook metadata, and since it is a limited set (from "Hathi Files", not MARC) searching it is super fast, less than a tenth of a second, typically.  

 

My problem is that the IDs used by Hathi sometimes include slashes and punctuation that break Zend routing to my controller.  For example loc.ark:/13960/t1xd12868:

 

So that is a real ID ("volume_id" in Hathi terms) and I cannot change it.  The existing value is required to build the link correctly.  How do I get Zend to permit it through routing, i.e. to make the placeholder "greedy"?  Do I need to base64 encode/decode it in and out to make it acceptable?

 

--Joe