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

Secondary resource representation not available #7

Closed
gaperik opened this issue Aug 28, 2015 · 3 comments
Closed

Secondary resource representation not available #7

gaperik opened this issue Aug 28, 2015 · 3 comments

Comments

@gaperik
Copy link

gaperik commented Aug 28, 2015

The current draft states "retry the request to the origin server without including
"out-of-band" in the Accept-Encoding request header field". What if the resource was not available because of the origin server deliberately having removed it using a separate procedure? In that case, the origin server may want to have the client use another secondary server?

@gaperik
Copy link
Author

gaperik commented Sep 3, 2015

A few thoughts about some possible guidelines for a solution we can discuss:

  1. There may be different reasons for the oob delivery to fail; secondary server not reachable, object not found, a content integrity check failing. This may be relevant information for an origin server in deciding whether to use a oob secondary server or not.
  2. The risk of a loop is there. Hence, it may be appropriate for the client to indicate that it does not accept OOB henceforth. It may depend on the actual error case.
  3. The origin server may have referred delivery of other resource to the secondary server than the one that the client failed to retrieve. What should be done about these? One solution may be to enable to origin server to provide a directive to the client to stop usage the oob secondary server for any resource.

@reschke
Copy link
Owner

reschke commented Sep 8, 2015

I'll try an approach in which we piggy-back this information to the GET request, using Link header fields.

Such as:

Link: <http://cache/resource>, rel=serverdown

with relation types for the common use cases we find.

@gaperik
Copy link
Author

gaperik commented Sep 8, 2015

Quite straight forward and a got starting point. More complex approaches like the report URI in CSP seem not applicable yet. Agree this is the first thing to try out.

@reschke reschke closed this as completed Sep 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants