htv:headers not conveyed when exposing thing

[kiesel]

When exposing a thing with http bindings, the htv:headers are emptied / not transported to the thing description of the exposed thing.

As an example, this is an excerpt of the td before exposing it:

  "properties": {
    "counter": {
      "type": "integer",
      "writeOnly": false,
      "readOnly": false,
      "forms": [
        {
          "htv:headers": [
            {
              "htv:fieldName": "Cache-Control",
              "htv:fieldValue": "max-age=0"
            }
          ]
        }
      ]
    },

After exposing, a href is there, but htv:headers has disappeared.

I believe it should be possible to provide values here.

[danielpeintner]

Note: at the moment all forms entries are pruned. The idea behind is that the "exposing" code is in charge of setting up form entries.

I think If additional information need to be passed we may need to find another way of doing that...but what should happen if the servient has internally different settings...

[relu91]

I think we can be more merciful and treat each form provided as a template. This complicates the validation but it has the potential to be more intuitive for the user.

[danielpeintner]

I agree, on the other side it is not that easy .. lets assume the example given above. Does it mean the additional stuff added should go into all binding forms. How can one specify it properly...

In this case due to htv:headers it might be obvious but this is surely not always the case.

[kiesel]

I agree with Daniel; actually not the thing should provide knowledge about the specific cache control headers in this example, but the exposing code. How would one achieve that, though? Do you have a pointer on the documentation for that for me?

OTOH, there's a discrepancy between how things are handled between this case and the case that a thing provides a Content-Type hint in the form.

Anyways, thank you for your responses so far!

[danielpeintner]

[...] not the thing should provide knowledge about the specific cache control headers in this example, but the exposing code. How would one achieve that, though? Do you have a pointer on the documentation for that for me?

No real pointer...
Having said that, I wonder whether this relates the Scripting API itself as well?
If not, we can try to find a way in node-wot how to set additional information...

[relu91]

Having said that, I wonder whether this relates the Scripting API itself as well?

yes, but I would start from implementation so that we can evaluate the algorithm concretely.

I think we can be more merciful and treat each form provided as a template. This complicates the validation but it has the potential to be more intuitive for the user.

Just to expand a little bit in this idea. We can take the items of the form property as templates that the protocol binding implementation can expand into the different network interfaces that it controls. But now we have the problem on how the core can understand if the template is for binding-http or binding-coap. In this case, we can use the rule of thumb, if it contains HTTP specific vocabulary then is it for binding-http. If the item contains both then it is an error and we throw an exception. If the template contains generic form keywords (i.e. content-type) then the template is for all the bindings aviable. What do you think?

[egekorkan]

I think allowing this kind of input from the node-wot users would start complicating stuff more than it should. The example I have seen here makes total sense but I have not seen in TDs so far. So node-wot binding-http would need to understand all this possible flexibility.

I am not sure how to really solve this but an additional config file or config as part of the HTTP config seems like one solution. Not intuitive but with good documentation, it should be ok?

This is also related to #51 and the associated PR

[relu91]

I am not sure how to really solve this but an additional config file or config as part of the HTTP config seems like one solution. Not intuitive but with good documentation, it should be ok?

The config file is good for global settings (i.e., all the things produced should have those headers), but what if you want to personalize stuff per thing? or even worst per form?

[egekorkan]

but what if you want to personalize stuff per thing? or even worst per form?

Yes this would be a use case to need this but then:

• Why would someone need form 2 to have a certain functionality? From my point of view, what is wanted in such use cases is that a form of an affordance has jpeg image type or all http forms of this affordance should have max age.

For me, it is weird that the produce method that is in the core needs or asks protocol information. Even if we do this, what can be put in a form must be documented and such forms should be strictly validated so that people do not have this expectation that any http header and its associated behaviour would be supported. I think that the real problem is the behavior that can be implied with such terms like max age. It is not enough to reflect this in the TD but additional implementation in the protocol bindings would be needed.

I have also just realized that this specific example's desired feature should be actually done in the affordance level with possibly new terms in the TD spec. If I am not wrong, @kiesel wants to tell the Consumers of this Thing that they should revalidate the cached value and in a way this is not a concept that is protocol specific, just that HTTP has built in mechanisms for it. This goes in line with some discussions @danielpeintner had about specifying the frequency of updates to a property w3c/wot-scripting-api#107 and w3c/wot-thing-description#1213 . If this goes in the TD spec, each binding can reflect on how this is described in the protocol level. This is of course a long discussion possibility :)

[danielpeintner]

May I add another proposal that comes to my mind. Maybe not very elegant and not applicable to the CLI but to bindings in general.

At the moment when developing we require the according client factory (and/or server part like HttpServer = require("@node-wot/binding-http").HttpServer;)

A possibility to add flexibility here could be to either

• add extension/configuration points to the existing bindings by well-known settings
  OR
• make it easy to extend the current implementation a la MyHttpServer extends HttpServer

Could that be an alternative?

[relu91]

For me, it is weird that the produce method that is in the core needs or asks protocol information. Even if we do this, what can be put in a form must be documented and such forms should be strictly validated so that people do not have this expectation that any http header and its associated behaviour would be supported. I think that the real problem is the behavior that can be implied with such terms like max age. It is not enough to reflect this in the TD but additional implementation in the protocol bindings would be needed.

Well, currently forms are generated by the specific protocol binding. Therefore, we can send all the templates to all the active bindings and they choose the one relevant to their business, or we can do as stated above but check only prefixes and do a prefix-protocolScheme mapping. Anyway, I agree that we should focus on the use case and evaluate if there is a real need for this.

Why would someone need form 2 to have a certain functionality? From my point of view, what is wanted in such use cases is that a form of an affordance has jpeg image type or all http forms of this affordance should have max age.

In my mind, there is this corner use case: how I can state that this affordance can serve a jpeg and a png image? I think that right now we have custom logic to handle this, but it would be nice to have a generic way (?).