Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Processor now requires URLs in a specific format #30

Open
francescopioscognamiglio opened this issue Apr 19, 2024 · 7 comments · Fixed by #36
Open

The Processor now requires URLs in a specific format #30

francescopioscognamiglio opened this issue Apr 19, 2024 · 7 comments · Fixed by #36
Assignees
Labels
bug Something isn't working

Comments

@francescopioscognamiglio

Hi all, I found an interesting issue while using the module.

Configuration

I'm using the latest version of the iiif-processor module: 4.0.4.

Problem

I got an error when creating a new Processor object passing a URL with this pattern: https://<domain>/.*/iiif/2/.*.
It seems that it is no longer possible to use this kind of pattern.
Going deeper, I see that a regex requires that between the domain and the /iiif/2 part there are no extra strings here https://github.com/samvera/node-iiif/blob/v4.0.4/src/processor.js#L19.

@mbklein
Copy link
Member

mbklein commented Apr 22, 2024

Thanks for bringing this issue to my attention. I'll take a look at it and see if I can come up with a solution. It might be as easy as removing the beginning-of-string anchor (^) from the regex.

@mbklein mbklein added the bug Something isn't working label Apr 22, 2024
@mbklein mbklein self-assigned this Apr 22, 2024
@tarjelavik
Copy link

I encountered this as well now. It would be great if this was more flexible. We plan to use /image/3/{id}, so the service broke unexpectedly.

@mbklein
Copy link
Member

mbklein commented Nov 18, 2024

Thanks; I'll try to get to this soon.

@mbklein
Copy link
Member

mbklein commented Nov 21, 2024

@tarjelavik The pull request referenced above should help once it's merged – you would pass { pathPrefix: "/images/{{version}}/" } in the constructor options and it should just work.

Are you using the package directly, or through serverless-iiif? If it's the latter, it'll take a little bit for the feature to work its way up through the stack.

@tarjelavik
Copy link

@mbklein Great! I tested the commit in my repo and it works :-). If i used iiif/image it didn't, but i guess that could be done with API gateways or what not (my first cloud experiment this).

No, i can't use the serverless-iiif as we are on Azure. I have rewritten serverless-iiif for Azure, only working locally but hope I can get help with the architecture bit. Very inspired by what Samvera have done with IIIF apps :-).

@mbklein
Copy link
Member

mbklein commented Nov 22, 2024

That is fantastic! Is your Azure version open source/hosted anywhere? I'd love to combine our efforts and maybe create a deployable Azure version that's linked from the main documentation site.

@mbklein mbklein reopened this Nov 22, 2024
@tarjelavik
Copy link

Great :-). It is hosted here: https://git.app.uib.no/uib-ub/cultural-heritage-collections/serverless-iiif-azure.

It is my first attempt at writing for Azure, and a lot was done with AI help. I don't think it is implemented very well, but it work well locally. It has not been tested on Azure, so the bicep IaC files are more a placeholder. I hope we can get help from our IT-department with the next steps. A link from serverless-iiif is a bit premature :-)

It would be great is your repo could support Azure as well, and given your experience with running it on in the cloud it would be a big help!
Maybe a new issue is more suitable for further discussion?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants