Remove errors?

[sandeepshetty]

The reason I din't have errors in the first place and used the 202 status code was to leave the option to do any processing asynchronously especially to avoid this becoming a ddos attack vector.

[pfefferle]

But with no error codes, it is not possible to write code that reacts on the error!

[sandeepshetty]

See the 0.2 branch. It distinguish between sender and receiver errors with the error msg as plaintext response body.

[pfefferle]

yes, but there are a lot of possibilities of an error on the sender site. The mentioned examples:

• Source URL not found.
• Specified target URL not found.
• Source URL does not contain a link to the target URL.
• Specified target URL does not accept webmentions.

Don't you think it's important to specify an error code for them so it is easier to find the error or to react directly within the code?

[pfefferle]

And I think "Specified target URL does not accept webmentions" should be a Receiver Error, because you can't know on client side or can you?

[sandeepshetty]

In most cases the source cannot do anything automatically to fix these. It usually requires a person to look at the error and fix it.

[sandeepshetty]

""Specified target URL does not accept webmentions" is a sender error because the sender sent it when the receiver did not advertise it's webmention endpoint.

[pfefferle]

"In most cases the source cannot do anything automatically to fix these" that's a good point!

"is a sender error because the sender sent it when the receiver did not advertise it's webmention endpoint." but if the sender does not advertise it's webmention endpoint, where does the client know the endpoint from?

[pfefferle]

but ok, these are only examples... you convinced me!

[sandeepshetty]

The "requires manual action" was from the indieweb wiki.

An example where a sender is at fault: An implementation that decides to cache webmention enpoints on a per domain where as the domain in question does an endpoint per URL.

[cweiske]

I might mark a sender domain as spam, and my webmention server would always error out on mention requests. Then the sender could automatically stop sending mentions to me.

Not having error codes and messages make it harder to classify, group and filter errors.

[barnabywalters]

Something new to consider: @adactio added a webmention sending form to his journal entries to help people who’s websites don’t support webmention already. Being able to test and use webmention through a human visible, interactable form is a huge benefit of using HTTP form encoded data.

We can make this an even stronger case by encouraging success and error responses to be full HTML documents with helpful copy.

See also

• http://tantek.com/2013/258/t2/web-protocols-should-use-http-params-no-xml
• http://adactio.com/journal/6469/
• http://adactio.com/journal/6495/

(originally posted at http://waterpigs.co.uk/notes/4SFH11/)

[pfefferle]

That is exactly how it is defined in 0.1 (html and json) so i would recommend to stay with the spec 0.1 Responses handling. Perhaps we define more generic json-keys and better defined HTML...

[pfefferle]

Switching to plain text also breaks backwards compatibility

[cweiske]

Switching to plain text also breaks backwards compatibility

Do you really want to keep BC with a 0.1 version? It's not 1.0 that is stable and defined for eternity.

[pfefferle]

No, but you argumented for a json version and barnaby for HTML... That means no need to change to plain text... And it is nice to be bc

[sandeepshetty]

See #22.