Content negotiation handling
nekr0z opened this issue · comments
Fetching a Plume page at https://blog.nataraj.ru/~/It/%D0%92%D1%8B%D0%BF%D1%83%D1%81%D1%82%D0%B8%D0%BB%20%D1%80%D0%B5%D0%BB%D0%B8%D0%B7%20%D0%B8%D0%B3%D1%80%D1%8B%20Goblin%20Camp%20v0.23 with just Accept: application/activity+json returns AS2 (as expected). Fetching the same URL with Accept: application/activity+json; q=0.9, application/ld+json;profile="https://www.w3.org/ns/activitystreams"; q=0.8, text/html; charset=utf-8; q=0.7 (as Bridgy Fed does, for example) returns HTML with no rel=alternate link pointing to AS2, thus making Fediverse interaction fail.
- Plume version: 0.7.2
- Operating system: Any
- Web Browser: Any
Plume should match on the application/activity+json; q=0.9 part but fails to because it doesn't understand the q=0.9 part (which it should), however the profile for the 2nd content type seems wrong, it lacks a final ". With it present, Plume seems to answer with a json document
Plume should match on the
application/activity+json; q=0.9part but fails to because it doesn't understand theq=0.9part (which it should), however the profile for the 2nd content type seems wrong, it lacks a final". With it present, Plume seems to answer with a json document
My bad, I only provided a part of the header that provokes the HTML response; here it is in full:
Accept: application/activity+json; q=0.9, application/ld+json;profile="https://www.w3.org/ns/activitystreams"; q=0.8, text/html; charset=utf-8; q=0.7
I've updated the top post, too.
rocket has some support for handling media types that on first glance looks like it would remove the need for custom parsing code for the more complex cases, and handlesq= values and parameters on media types: https://api.rocket.rs/v0.4/rocket/http/struct.Accept.html