AP fetches are initiated with non-compliant Accept header #730

Closed
opened 2024-04-01 23:13:59 +00:00 by Oneric · 0 comments
Member

Your setup

From source

Extra details

Alpine 3.19

Version

2d439034ca

PostgreSQL version

16

What’s wrong?

Section 3.2 of the ActivityPub spec 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.

But currently, we perform fetches with application/activity+json instead

[{"accept", "application/activity+json"}]

The same section also tells us

Servers MAY use HTTP content negotiation as defined in [RFC7231] to select the type of data to return in response to a request, but MUST present the ActivityStreams object representation in response to application/ld+json; profile="https://www.w3.org/ns/activitystreams", and SHOULD also present the ActivityStreams representation in response to application/activity+json as well.

The SHOULD part is why we have (currently) little trouble with this in practice, but still we shouldn’t break spec here for no reason.

Just changing the one linked line is likely enough for the server, but some tests only mock HTTP responses for application/activity+json requests and will need updating too

I guess, ideally we also update the returned Content-Type header when serving an AP object (though afaict there isn’t any spec requirement about this, albeit ActivityStream spec seems to actually prefer application/activity+json)

Severity

I can manage

Have you searched for this issue?

  • I have double-checked and have not found this issue mentioned anywhere.
### Your setup From source ### Extra details Alpine 3.19 ### Version 2d439034ca ### PostgreSQL version 16 ### What’s wrong? [Section 3.2 of the ActivityPub spec](https://www.w3.org/TR/activitypub/#retrieving-objects) 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. But currently, we perform fetches with `application/activity+json` instead https://akkoma.dev/AkkomaGang/akkoma/src/commit/2d439034ca801b704536cb05483e012d62c2d52e/lib/pleroma/object/fetcher.ex#L327 The same section also tells us > Servers *MAY* use HTTP content negotiation as defined in [RFC7231] to select the type of data to return in response to a request, but *MUST* present the ActivityStreams object representation in response to `application/ld+json; profile="https://www.w3.org/ns/activitystreams"`, and *SHOULD* also present the ActivityStreams representation in response to `application/activity+json` as well. The *SHOULD* part is why we have (currently) little trouble with this in practice, but still we shouldn’t break spec here for no reason. Just changing the one linked line is likely enough for the server, but some tests only mock HTTP responses for `application/activity+json` requests and will need updating too I guess, ideally we also update the returned `Content-Type` header when *serving* an AP object *(though afaict there isn’t any spec requirement about this, albeit ActivityStream spec seems to actually prefer `application/activity+json`)* ### Severity I can manage ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.
Oneric added the
bug
label 2024-04-01 23:13:59 +00:00
Oneric changed title from AP fetches are initiaed with noncompliant Accept header to AP fetches are initiaed with non-compliant Accept header 2024-04-01 23:15:03 +00:00
Oneric changed title from AP fetches are initiaed with non-compliant Accept header to AP fetches are initiated with non-compliant Accept header 2024-04-11 21:00:56 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#730
No description provided.