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 referenced this issue from a commit

2024-04-11 20:48:17 +00:00

Use standard-compliant Accept header when fetching

Oneric referenced this issue

2024-04-11 20:59:24 +00:00

Use standard-compliant Accept header when fetching #740

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

Oneric referenced this issue from a commit

2024-04-11 22:29:40 +00:00

Use standard-compliant Accept header when fetching