Repository navigation
Section 3.2: no language support #57
Description
[raised by Addison Phillips, discussed in i18n telecon]
https://www.w3.org/TR/webmention/#receiving-webmentions
Section 3.2 say (in part):
The response body MAY contain content, in which case a human-readable response is recommended.
There is no mention of language negotiation or language identification here. The assumption appears to be that a wad of English is returned? ;-)
The example could include a Content-Language header or might allow for other language identification in the body (complicated)
This is also applicable to at least 3.2.3 Error Responses as well.
If the Webmention was not successful because of something the sender did, it MUST return a 400 Bad Request status code and MAY include a description of the error in the response body.
Activity
aaronpk commentedon Jul 13, 2016
Thanks for bringing this up. The response body is not meant to be visible to end users, and is only informative, since the HTTP code indicates the actual status of the request. Some implementations return a JSON body or no body as well, while others return text such as "Success".
Given that there is no functionality specified by returning a response body, do you think it would be appropriate to just drop "in which case a human-readable response is recommended."?
For error responses, these again are not meant to be visible to the end user, and only useful in development. What is the normal recommendation for returning error messages intended to be seen only be developers?
akuckartz commentedon Jul 13, 2016
As an end user I have seen many errors intended to be seen only by developers.
kevinmarks commentedon Aug 2, 2016
If we update the normative reference to HTTP 1.1 to RFC 7231, we can delegate the response body to https://tools.ietf.org/html/rfc7231#section-6.5 (ie the language identification is done in the usual way for HTTP, and not needed to be specified by webmention)
sandhawke commentedon Aug 3, 2016
Changing a normative reference would normally necessitate another CR. Or is the charge in reference purely editorial?
aaronpk commentedon Aug 3, 2016
The spec references HTTP 1.1 (RFC2616) in two places, when talking about sending the HEAD request, and when talking about returning the HTTP status code. Changing the reference to 7231 would not have any implications of changing existing implementations if that's what you mean.
kevinmarks commentedon Aug 3, 2016
I don't think we use the parts of HTTP 1.1, that were ambiguous in 2616, but referencing the better spec is worth it in terms of leading implementers to the current state of understanding. Mark Nottingham wrote about the differences here: https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead
Sorry I didn't catch this reference earlier.
sandhawke commentedon Aug 3, 2016
That sounds like it should be okay, but as part of the PR transition, we'll have to make the case that the change isn't a problem.
aaronpk commentedon Sep 22, 2016
notes from f2f discussion:
Accept: */*header so you always get some responseaaronpk commentedon Sep 22, 2016
Notes from discussion with i18n:
remove english example from response body