I figured this out, just want to post in case anyone runs into this in the future and has the same problem. The Apache directive controlling this is the Multiviews Option being declared on the Apache root directory, like this: <Directory /var/www/> Options Indexes FollowSymlinks Multiviews AllowOverride None Order allow,deny allow from all </Directory> From the Apache web site: "A Multiviews search is enabled by the Multiviews Options. If the server receives a request for /some/dir/foo and /some/dir/foo does not exist, then the server reads the directory looking for all files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client's requirements, and returns that document." Doug -----Original Message----- From: Doug Dearden Sent: Friday, November 11, 2016 4:45 PM To: Doug Dearden <dearden@sarsf.org>; koha@lists.katipo.co.nz Subject: RE: Change in behavior after upgrade Update: I am serving these images from the default apache server. I compared my new 000-default.conf to my old one, and realized I had a lot of directives in the old that were not in the new. I added them in and the new catalog is now behaving as the old one did. So it's an apache configuration thing. I don't have any rewriterule directives, so I am still not sure of the cause. Will dig further into the directives and see if I can figure it out. Still open to suggestions. Doug -----Original Message----- From: Koha [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Doug Dearden Sent: Friday, November 11, 2016 3:14 PM To: koha@lists.katipo.co.nz Subject: [Koha] Change in behavior after upgrade Hello all, We recently upgraded from version 3.16.03.000 to 16.05.05.000 and I migrated to a new server at the same time. We have three catalogs including one where we have scanned archival items. The link to these items was then placed in the 856$u field and the electronic format in the 856$q field. Typically this looks like 856$u /directory1/directory2/foo.jpg | 856$q jpg . Somewhere along the line on the old system, the librarian cataloging these images found that she could put in the path to the file in 856$u as just /directory1/directory2/foo and put the mime extension in 856$q and the image would appear when the link was clicked on. The actual file on the server is foo.jpg and there is no file just named foo . After our migration and upgrade, this no longer works as before. Since the old machine is still running, I verified that this was the case and indeed, a link on the old one that says /directory1/directory2/foo opens the scanned image. The url in the browser address windows says /directory1/directory2/foo . If I change the url to /directory1/directory2/foo.jpg the image also appears . On the new machine things changed. /directory1/directory2/foo returns the error "Not Found The requested URL /directory1/directory1/foo was not found on this server". Changing the url to /directory1/directory2/foo.jpg fixes things and returns the image. Did something change in Koha? I am suspicious that this is an Apache or Linux thing, but am baffled why this even works on the old one without the complete file name. I am thinking I need to write some SQL to append the 856$q text onto the 856$u to fix this, but if there is a config I need to change somewhere to get back to the old behavior that would be easiest. I am open to any suggestions. Thanks, Doug Dearden, Director, IT School for Advanced Research PO Box 2188 Santa Fe, NM 87504-2188 505-954-7220 www.sarweb.org<http://www.sarweb.org> [http://sarweb.org/media/files/sar_email_logo.png] Advancing innovative social science research and promoting Native American creativity. Expand your understanding of the human experience at www.sarweb.org<http://www.sarweb.org>. _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha