Remove errors? #9

Closed
sandeepshetty opened this Issue Jun 10, 2013 · 16 comments

Comments

Projects
None yet
4 participants
Owner

sandeepshetty commented Jun 10, 2013

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.

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

Owner

sandeepshetty commented Jun 26, 2013

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

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?

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?

Owner

sandeepshetty commented Jun 26, 2013

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.

Owner

sandeepshetty commented Jun 26, 2013

""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.

"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?

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

Owner

sandeepshetty commented Jun 26, 2013

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 commented Sep 25, 2013

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.

Contributor

barnabywalters commented Sep 27, 2013

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

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

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...

Switching to plain text also breaks backwards compatibility

cweiske commented Sep 27, 2013

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.

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

Owner

sandeepshetty commented Sep 30, 2013

See #22.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment