-
Notifications
You must be signed in to change notification settings - Fork 0
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
Onderscheid op accept header toelaten #86
Comments
Zelfde fix is nodig voor toevalsvondsten Indien JSON dan willen we naar https://test-loket.onroerenderfgoed.be/archeologie/vondstmeldingen/toevalsvondsten/545 (huidige standaard gedrag), indien HTML dan willen we naar /beheer (https://test-loket.onroerenderfgoed.be/archeologie/vondstmeldingen/toevalsvondsten/beheer) met het juiste ID geopend |
Wat als er een mime-type gevraagd wordt dat niet gedefinieerd is? |
Lijkt me een implementatie van 4.3 in https://www.w3.org/TR/cooluris/ te zijn. |
|
Voorstel in pseudo code:
|
Akkoord met voorstel van Bram (met de default optie). Was even vergeten dat er een HTTP 406 was. Mooie oplossing! |
Mag ik nog een kleine syntax change in de yaml voorstellen: - match: '^/archeologie/metaaldetectievondstmeldingen/(?P<id>\d+)$'
redirect:
text/html: 'https://@@archeologie.url@@/metaaldetectievondstmeldingen/beheer/#/{id}'
application/json: 'https://@@archeologie.url@@/metaaldetectievondstmeldingen/metaaldetectievondsten/{id}' Dan zit onder
Dat eerste lijkt mij logischer, en je kan dan ook geen dubbele mimetypes hebben als bonus. Als de request geen accept header definieert (en dus eigenlijk zegt alles te accepteren). Wil ik dan random het eerste nemen, of wil ik manueel op zoek gaan of text/html bestaat eerst? |
Indien er een default key is voorzien -> redirect naar de waarde die daar is opgegeven. |
Zou dat niet gaan overlappen met browser calls? Browsers sturen altijd |
Na daily: Ik begreep bram zijn opmerking verkeerd. Hij bedoelde dat er in de yaml ergens een "default" key zou zijn. Dat is wel mogelijk. |
https://test-id.erfgoed.net/archeologie/metaaldetectievondstmeldingen/716 geeft 500 fout
Dit is de yaml
|
Ik denk dat de urihandler package nog niet goed geupdate is als ik de lijn nummers zo zie. |
hm, ok. Ik bekijk het |
Het probleem was dat de versie van de urihandler package niet veranderd is op develop waardoor het package niet werd geupdated Na een pip uninstall urihandler en nieuwe install was bovenstaande probleem voorbij Nog 1 ander probleem Dit is mijn config
Ik krijg een 406 voor https://dev-id.erfgoed.net/archeologie/metaaldetectievondstmeldingen/1 en Accept: application/xml, ik verwacht de erfgoedobjecten url |
Ah, dat heb ik fout begrepen dan. Ik had in mijn hoofd dat default enkel was voor het geval van dat er geen accept header aanwezig was. |
ah nee, default is de opvangbak van alle headers. Als alle gedefinieerde keys zijn gecontroleerd en we hebben geen match met onze header, dan is dit de redirect voor alles. Eerst moeten dus wel eerst alle keys gecontroleerd hebben want met voorkeur matchen we op het juiste type. |
Nu ziet een regel er zo uit:
We zouden iets zoals dit willen ondersteunen:
Misschien niet meer dan hier extra check op u[redirect] is list => filteren op u[redirect][request.accept] of zoets?
The text was updated successfully, but these errors were encountered: