Wrong forwarding URL when registrateion URL omits path

[fgalan]

(Comes from discussion at https://github.com/FIWARE/specifications/issues/13)

Rule to compose forwarding URL for Context Providers is as follow:

• Queries: <url as used in context registration> + "/op/query"
• Update: <url as used in context registration> + "/op/update"

When the URL in the registration doesn't omit path (e.g. "http://iot-agent:1880/v2" or "http://iot-agent:1880/") this works fine and the rule is applied correctly, i.e:

• "http://iot-agent:1880/v2" + "/op/query" = "http://iot-agent:1880/v2/op/query"
• "http://iot-agent:1880/" + "/op/query" = "http://iot-agent:1880//op/query" (in this case the // is weird, but it what the user wants if he/she uses "http://iot-agent:1880/" in the registration URL)

However, if the URL in the registration omits path (e.g. "http://iot-agent:1880") then is not working correctly: instead of "http://iot-agent:1880/op/query" we get "http://iot-agent:1880//op/query"

[fgalan]

@piwo1984 could you have a look to check if my description of the issue above is fully correct, please? Thanks!

[fgalan]

Rule to compose forwarding URL for Context Providers is as follow:

I'm not sure if that rule is explicitly specified in documentation (https://fiware-orion.readthedocs.io/en/master/user/context_providers/index.html). In negative case, as part of this issue, documentation should be modified to include it.

[piwo1984]

@fgalan yes your description is correct.

[Anjali-NEC]

Hi @fgalan Sir,

I would like to work on this issue, Please let me know this issue still need a fix or not?

[fgalan]

@Anjali-NEC the issue is still valid. Thanks for your willingness to work on it!

The difficult thing here is maybe to create the .test to assess the fix, as you need to inspect the URL to which the request is forwarded in order to check that it's working as expected. Not sure right now if accumulator-server.py could be used in that way (maybe need to be extended with an ad hoc route).

[Anjali-NEC]

@Anjali-NEC the issue is still valid. Thanks for your willingness to work on it!

The difficult thing here is maybe to create the .test to assess the fix, as you need to inspect the URL to which the request is forwarded in order to check that it's working as expected. Not sure right now if accumulator-server.py could be used in that way (maybe need to be extended with an ad hoc route).

Due to complexity for creating the .test for this issue, I looking for another issue.