Content negotiation handling

[nekr0z]

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

[trinity-1686a]

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

[nekr0z]

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

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.

[sknebel]

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