Fix Accept headers when fetching AP objects to match spec #30354
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ActivityPub spec section 3.2 reads > The client MUST specify an Accept header with the > `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` > media type in order to retrieve the activity. Currently Mastodon omits the profile in its dereferences (but not the fetch service) and only lists application/ld+json as one of several possible types. This breaks spec and allows spec-compliant implementations to refuse any such fetch requests. Resolve this by adding the required profile and while at it, make the only spec-compliant type the first listed choice in all relevant places. While unlikely to be a problem due to other parts already including a profile, also keep a profile-less JSON-LD type where it existed before to ensure this doesn't break federation with a hypothetical buggy implemenetation relying on this current Mastodon quirk. Section 7 also specifies the same media type MUST be used in the Content-Type header of for POST requests, but here we can't specify alternatives, so for now keep the current type. Fixes a part of mastodon#22720
|
The CI failure for Let me know if i missed and should fix something |
|
This looks like to be a flaky test. Maybe @mjankowski want to have a look? |
|
I don't see the failure at that link, but I think I found it here - https://github.com/mastodon/mastodon/actions/runs/9134408456/job/25122194677 - and yeah, might be a sort-order dependent intermittent failure ... will see if I can replicate locally. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ActivityPub spec section 3.2 reads
Currently Mastodon omits the profile in its dereferences (but not the fetch service) and only lists application/ld+json as one of several possible types. This breaks spec and allows spec-compliant implementations to refuse any such fetch requests.
Resolve this by adding the required profile and while at it, make the only spec-compliant type the first listed choice in all relevant places.
While unlikely to be a problem due to other parts already including a profile, also keep a profile-less JSON-LD type where it existed before to ensure this doesn't break federation with a hypothetical buggy implemenetation relying on this current Mastodon quirk.
Section 7 also specifies the same media type MUST be used in the Content-Type header of for POST requests, but here we can't specify alternatives, so for now keep the current type.
Fixes a part of #22720
This is a more conservative alternative to #22722.
POSTrequests are left with the non-compliantapplication/acitivity+json; i believe those should be changed to match spec too but afaik there’s no way to do this without fully removing the current type. If there’s any interest in doing so anyway, i’d be happy to add changes for them tooWith the proper spec-compliant type now being the first choice on fetches at least, hopefully we’ll get less cases like #22722 (comment)