-
Notifications
You must be signed in to change notification settings - Fork 22
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
Metadata: Proxy #81
Comments
Here is Matthias' example:
I think we can express this using something like:
In other words, if a value (a URL) is given for a proxy, then the configuration is for the proxy. The other configurations would then be used for the endpoints.
|
Zoltan commented: an explicit example of how schemes and protocols can be combined would be useful... |
Not sure what schemes and combinations we should look at in the short term. At least basic, oauth, and ocf. What I don't know is whether certain combinations make sense, eg OAuth with CoAP. I'll make a table and may simply mark certain combinations as "unsupported" for now. Basically: (basic, oauth, ocf) x (http, coap). For now, just support (basic,http), (oauth,http), and (ocf,coap) for initial testing. Later on we can add more. |
Will leave open until I generate and we review a PR with the suggested changes. |
See PR #86 |
From A proxy probably needs to be combined with any other "scheme". So a |
The way I have set this up if proxyURL is given the entire configuration is for a proxy. If it is not given, it is for the endpoint. The then need to list multiple configurations for all “forms” that use proxies. This approach lets you use whatever security configuration you want for the proxy and use a completely independent configuration for the endpoint. I should probably try to clarify the example. |
I should comment that in the current proposal you can have multiple configurations using the "basic" scheme, eg. one for an endpoint, one for the proxy. This is another reason not to use scheme names as "tags" eg : in a map, because then you could only use each scheme once. The proposal (using { "scheme": , ... } allows each scheme to be used multiple times. I do need to improve the writeup now that we've seen some feedback. I have to generate an HTML-based PR for the TD spec anyway... |
Within
Within Interactions:
P.S.: I am still not sure if we should use all lower-case value terms or camel-case for |
My issue with
Thus, |
I think this is resolved but we should wait until after the Bundang plugfest and implementation feedback from Matthias. One issue is dealing with both protocol-aware proxies (eg HTTP Proxy) and transparent (application-level) proxies. These may require different strategies. |
Going to close this, consider it done, but can raise new issues after testing. I propose to add an explicit checkpoint to the plugfest planning document to test that we have the right metadata here, then close this issue. |
OK, will really close this now. I think Matthias' point about the appearance of the "proxy" field should really change the "type" of the scheme is kind of relevant, but I think the rule is clear enough (if "proxy" appears, the scheme is for the proxy). |
A proxy requires a separate URL to access it. A standard tag should be used for this when it is needed. The example from Matthias uses "href". However, should this be embedded in another access scheme, or have its own scheme? For HTTP proxies, do we need to specify anything different from "http"? What about non-HTTP proxies, eg. specifically for WoT systems?
The text was updated successfully, but these errors were encountered: