Re-add wildcard types and modify checks for acceptable types.

[whikloj]

JIRA Ticket: https://fedora-repository.atlassian.net/browse/FCREPO-3810

What does this Pull Request do?

Re-adds wildcards to the Jersey endpoints otherwise Jersey rejects Accept headers that aren't in the list (which are all RDF types and text/plain and text/html).

Also makes HEAD requests respond the same as a GET request.

How should this be tested?

Before this PR.
Put up a binary that is not text/plain or text/html (you can put up plain text and claim it is application/pdf though)
ie.

> curl -ufedoraAdmin:fedoraAdmin -XPUT -H"Content-type: application/pdf" --data-binary "Some fake binary" http://localhost:8080/rest/test_binary

HTTP/1.1 201 Created

Do a HEAD request to see the Content-type is set correctly.

> curl -I -ufedoraAdmin:fedoraAdmin http://localhost:8080/rest/test_binary

HTTP/1.1 200 OK
...
Content-Type: application/pdf
...

Now do a HEAD and/or GET request using that mimetype with the Accept header.

> curl -I -ufedoraAdmin:fedoraAdmin http://localhost:8080/rest/test_binary -H"Accept: application/pdf"

HTTP/1.1 406 Not Acceptable

> curl -i -ufedoraAdmin:fedoraAdmin http://localhost:8080/rest/test_binary -H"Accept: application/pdf"

HTTP/1.1 406 Not Acceptable

Pull in this PR, rebuild and try getting them again.

> curl -I -ufedoraAdmin:fedoraAdmin http://localhost:8080/rest/test_binary -H"Accept: application/pdf"             

HTTP/1.1 200 OK

> curl -i -ufedoraAdmin:fedoraAdmin http://localhost:8080/rest/test_binary -H"Accept: application/pdf"             

HTTP/1.1 200 OK

But it still fails if the type is not compatible.

> curl -i -ufedoraAdmin:fedoraAdmin http://localhost:8080/rest/test_binary/fcr:metadata -H"Accept: application/pdf"

HTTP/1.1 406 Not Acceptable

> curl -i -ufedoraAdmin:fedoraAdmin http://localhost:8080/rest/test_binary -H"Accept: image/tiff"                  

HTTP/1.1 406 Not Acceptable

Interested parties

Tag (@ mention) interested parties or, if unsure, @fcrepo/committers

[dbernstein]

Nice work @whikloj. Code looks good and it works as advertised.

[bbpennel]

This looks good to me and is functioning as I would expect for GET and HEAD requests. The only thing I am wondering is if the integration test should verify that */* accept header works as well (which it does in manual testing, but yeah).

[whikloj]

I will add that in.

…

On Fri., Mar. 11, 2022, 1:31 p.m. Ben Pennell, ***@***.***> wrote: ***@***.**** approved this pull request. This looks good to me and is functioning as I would expect for GET and HEAD requests. The only thing I am wondering is if the integration test should verify that */* accept header works as well (which it does in manual testing, but yeah). — Reply to this email directly, view it on GitHub <#1977 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVZVYOYGYX6FABK5V4YBYLU7ONQFANCNFSM5P3UEYUQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[bbpennel]

For RDF sources, should we verify that Accept: */* works as well?

[whikloj]

Sorry about that, I read the need for testing */* and then I focused on Head versus Get in the RDF realm. I hope these changes cover everything.

[bbpennel]

Looks good!