Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove errors? #9

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

Comments

Projects
None yet
4 participants
@sandeepshetty
Copy link
Member

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.

@pfefferle

This comment has been minimized.

Copy link

pfefferle commented Jun 26, 2013

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

@sandeepshetty

This comment has been minimized.

Copy link
Member Author

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.

@pfefferle

This comment has been minimized.

Copy link

pfefferle commented Jun 26, 2013

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

This comment has been minimized.

Copy link

pfefferle commented Jun 26, 2013

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

This comment has been minimized.

Copy link
Member Author

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.

@sandeepshetty

This comment has been minimized.

Copy link
Member Author

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.

@pfefferle

This comment has been minimized.

Copy link

pfefferle commented Jun 26, 2013

"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

This comment has been minimized.

Copy link

pfefferle commented Jun 26, 2013

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

@sandeepshetty

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link

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.

@barnabywalters

This comment has been minimized.

Copy link
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/)

@pfefferle

This comment has been minimized.

Copy link

pfefferle commented Sep 27, 2013

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

This comment has been minimized.

Copy link

pfefferle commented Sep 27, 2013

Switching to plain text also breaks backwards compatibility

@cweiske

This comment has been minimized.

Copy link

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.

@pfefferle

This comment has been minimized.

Copy link

pfefferle commented Sep 27, 2013

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

This comment has been minimized.

Copy link
Member Author

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
You can’t perform that action at this time.