Yup, for example in the topic you linked.
That’s a “feature” (of sorts) you see in some AP platforms. I’d note that the ActivityPub spec provides:
The HTTP GET method may be dereferenced against an object’s
id
property to retrieve the activity. 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 toapplication/ld+json; profile="https://www.w3.org/ns/activitystreams"
, and SHOULD also present the ActivityStreams representation in response toapplication/activity+json
as well. The client MUST specify anAccept
header with theapplication/ld+json; profile="https://www.w3.org/ns/activitystreams"
media type in order to retrieve the activity.
See also “Serialization” in Activity Streams 2.0.
The AP plugin currently requires you to send an Accept
header with either “application/ld+json” or “application/activity+json” to retrieve any object (i.e. Activity, Note etc). We may support what you’re referring to in the future, but it’s somewhat of a “power user” feature of specific platforms.