Subject: [core] HTTP/CoAP proxy setup

From: Oliver Kleine <[email-masked]>
Date: Mon, 23 Mar 2015 17:50:34 +0100

Dear all,

I'm currently trying to set up a scenario to test HTTP/CoAP proxying 
using a forward proxy and a common HTTP Web Browser such as Chrome or 
Firefox as a client. The current draft for HTTP/CoAP Mapping at

https://tools.ietf.org/html/draft-ietf-core-http-mapping-06

only covers the reverse proxy case using the "origin-form":

GET /path/to/service
Host: example.org

to define the target URL within the HTTP request. This implies some CoAP 
scheme as the predefined target URL scheme. For forwarding proxies in 
general the HTTP request is supposed to contain the target URL in 
"absolute-form":

GET coap://example.org/path/to/service

which is supposed to be automatically set if the browser is configured 
to use a proxy. This seems to work fine with http(s)-URLs but not for 
coap-URLs.

I tried some addons like ProxyFoxy for Firefox and SwitchySharp for 
Chrome but the URL pattern "coap*" leads to unexpected behaviour. For 
e.g. Chrome a coap-URL in the address bar leads to an unintended Google 
search for the given URL and not to the intended HTTP request to the 
proxy configured to handle requests to "coap*".

Furthermore, I found this 3 years old thread:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19582

but no solution. Is there any progress so far? Or, even better, could 
someone recommend a proxy plugin which is able to properly deal with the 
URL-pattern "coap://*"?

Thank you and best regards,
Oliver
-- 

Oliver Kleine, M.Sc.

UNIVERSITÄT ZU LÜBECK
     INSTITUT FÜR TELEMATIK

     Ratzeburger Allee 160
     23538 Lübeck

     Tel +49 451 500 5396
     Fax +49 451 500 5382
     [email-masked]

     https://www.itm.uni-luebeck.de/people/kleine

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 24 Mar 2015 08:14:18 +0000

Hello Oliver,

I don't have an answer to your question on forward proxying - the problems you mention are exactly the reason we have defined the reverse proxy case in draft-ietf-core-http-mapping-06 so that there is never a need to enter a "coap://" URI inside a HTTP request. So the case covered in draft-ietf-core-http-mapping-06 is slightly different than you mentioned  - for example like this

GET /path/to/hcproxy/coap://example.org/path/to/service
Host: httpserver.example.org

So the knowledge on which of coap/coaps scheme to use is encoded by default inside the path.
This should work from any web browser.

Regards
Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Oliver Kleine
Sent: Monday, March 23, 2015 17:51
To: [email-masked]
Subject: [core] HTTP/CoAP proxy setup

Dear all,

I'm currently trying to set up a scenario to test HTTP/CoAP proxying using a forward proxy and a common HTTP Web Browser such as Chrome or Firefox as a client. The current draft for HTTP/CoAP Mapping at

GET /path/to/service
Host: example.org

to define the target URL within the HTTP request. This implies some CoAP scheme as the predefined target URL scheme. For forwarding proxies in general the HTTP request is supposed to contain the target URL in
"absolute-form":

which is supposed to be automatically set if the browser is configured to use a proxy. This seems to work fine with http(s)-URLs but not for coap-URLs.

I tried some addons like ProxyFoxy for Firefox and SwitchySharp for Chrome but the URL pattern "coap*" leads to unexpected behaviour. For e.g. Chrome a coap-URL in the address bar leads to an unintended Google search for the given URL and not to the intended HTTP request to the proxy configured to handle requests to "coap*".

but no solution. Is there any progress so far? Or, even better, could someone recommend a proxy plugin which is able to properly deal with the URL-pattern "coap://*"?

Oliver Kleine, M.Sc.

UNIVERSITÄT ZU LÜBECK
     INSTITUT FÜR TELEMATIK

     Ratzeburger Allee 160
     23538 Lübeck

     Tel +49 451 500 5396
     Fax +49 451 500 5382

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Oliver Kleine <[email-masked]>
Date: Tue, 24 Mar 2015 14:45:18 +0100

Hello Esko,

thanks a lot! That's quite similar to the solution I've been using since 
two years ago. The only differnce is that I did not encode the scheme in 
the path but as a query parameter such as

GET /proxy?uri=coap://...

I'm not sure if it is "allowed" to give query parameters to be handled 
by the proxy. But I could imagine that there may be diserable to add 
something like "do not use cached responses that are older than X" 
encoded as query parameter "?max-age-from-cache=X". That parameter is 
not intended to be forwarded to the CoAP server, i.e. included into the 
CoAP request but to be handled by the proxy.

Following the example in 5.2.2 of your current draft it seems, that 
query parameters are generally to be added to the CoAP request. Is that 
correct?

Thanks again and best,
Oliver

On 24.03.2015 09:14, Dijk, Esko wrote:
> Hello Oliver,
>
> I don't have an answer to your question on forward proxying - the
> problems you mention are exactly the reason we have defined the
> reverse proxy case in draft-ietf-core-http-mapping-06 so that there
> is never a need to enter a "coap://" URI inside a HTTP request. So
> the case covered in draft-ietf-core-http-mapping-06 is slightly
> different than you mentioned  - for example like this
>
> GET /path/to/hcproxy/coap://example.org/path/to/service Host:
> httpserver.example.org
>
> So the knowledge on which of coap/coaps scheme to use is encoded by
> default inside the path. This should work from any web browser.
>
> Regards Esko
>
> -----Original Message----- From: core [mailto:[email-masked]]
> On Behalf Of Oliver Kleine Sent: Monday, March 23, 2015 17:51 To:
> [email-masked] Subject: [core] HTTP/CoAP proxy setup
>
> Dear all,
>
> GET /path/to/service Host: example.org
>
> to define the target URL within the HTTP request. This implies some
> CoAP scheme as the predefined target URL scheme. For forwarding
> proxies in general the HTTP request is supposed to contain the target
> URL in "absolute-form":
>
> which is supposed to be automatically set if the browser is
> configured to use a proxy. This seems to work fine with http(s)-URLs
> but not for coap-URLs.
>
> e.g. Chrome a coap-URL in the address bar leads to an unintended
> Google search for the given URL and not to the intended HTTP request
> to the proxy configured to handle requests to "coap*".
>
> someone recommend a proxy plugin which is able to properly deal with
> the URL-pattern "coap://*"?
>
> Thank you and best regards, Oliver --
>
> Oliver Kleine, M.Sc.
>
>
> UNIVERSITÄT ZU LÜBECK INSTITUT FÜR TELEMATIK
>
> Ratzeburger Allee 160 23538 Lübeck
>
> Tel +49 451 500 5396 Fax +49 451 500 5382 [email-masked]
>
> ________________________________ The information contained in this
> message may be confidential and legally protected under applicable
> law. The message is intended solely for the addressee(s). If you are
> not the intended recipient, you are hereby notified that any use,
> forwarding, dissemination, or reproduction of this message is
> strictly prohibited and may be unlawful. If you are not the intended
> recipient, please contact the sender by return e-mail and destroy all
> copies of the original message.
>

-- 

Oliver Kleine, M.Sc.

UNIVERSITÄT ZU LÜBECK
     INSTITUT FÜR TELEMATIK

     Ratzeburger Allee 160
     23538 Lübeck

     Tel +49 451 500 5396
     Fax +49 451 500 5382

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 24 Mar 2015 14:34:42 +0000

Hi,

the default mapping (Section 5.2.*) indeed does *not* allow extra query parameters for use by the HC proxy. All the query parameters are going to the CoAP server. A non-default custom mapping function can be used to pass parameters to the HC proxy.

For example an enhanced form of URI mapping template (Section 5.3.2) can be used:

        {+s}://{+hp}/{+p}?q={+q}

If the HTTP client needs to access say the following CoAP URI:

        coaps://s.example.com/light?on

and also pass a parameter to the HC proxy, it can use:

        http://p.example.com/hc/coap://s.example.com/light?q=on&max-age-from-cache=55

(In case that the query component intended for the CoAP server gets more complex (e.g. "?foo=4&bar=2") some percent encoding needs to be applied to make it all work. But we didn't look at that aspect in the I-D.)
Using enhanced form also the example you gave of scheme as a parameter can be realized.

regards
Esko

-----Original Message-----
From: Oliver Kleine [mailto:[email-masked]]
Sent: Tuesday, March 24, 2015 14:45
To: Dijk, Esko; [email-masked]
Subject: Re: [core] HTTP/CoAP proxy setup

Hello Esko,

Thanks again and best,
Oliver

--

Oliver Kleine, M.Sc.

UNIVERSITÄT ZU LÜBECK
     INSTITUT FÜR TELEMATIK

     Ratzeburger Allee 160
     23538 Lübeck

     Tel +49 451 500 5396
     Fax +49 451 500 5382

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 24 Mar 2015 17:10:36 +0100

Hi Oliver!

Oliver Kleine wrote:
> But I could imagine that there may be diserable to add something
> like "do not use cached responses that are older than X" encoded as query
> parameter "?max-age-from-cache=X". That parameter is not intended to be
> forwarded to the CoAP server, i.e. included into the CoAP request but to be
> handled by the proxy.

HTTP actually provides a header field exactly for this purpose, namely
the Cache-Control header field [1]:

   Cache-Control: max-age=X

  "The 'max-age' request directive indicates that the client is
   unwilling to accept a response whose age is greater than the
   specified number of seconds."

Klaus

[1] http://tools.ietf.org/html/rfc7234#section-5.2

---

From: Oliver Kleine <[email-masked]>
Date: Wed, 25 Mar 2015 12:17:56 +0100

Hello Esko and Klaus,

thank you for your answers. I've been thinking about the "extra query 
parameters for the HC proxy" case and it in deed seems useless for 
reverse proxies. As from the perspective of the client a reverse proxy 
is yet another server it does not make sense to have some query 
parameters to be processed by the proxy and some to be forwarded.

This may be different for forwarding proxies since the client "knows" 
that it is talking to a proxy and not directly to a server. However, my 
"max-age-from-cache" example was a bad one (as Klaus pointed out). I 
don't know a better use-case which is not covered by some HTTP header. 
The question was intended rather general, i.e. "is there a way to 
distinguish query parameters to be processed by the proxy from those to 
be processed by the server?". But now I think, this seems to be needless 
for reverse proxies, anyway.

Best,
Oliver

On 24.03.2015 15:34, Dijk, Esko wrote:
> Hi,
>
> the default mapping (Section 5.2.*) indeed does *not* allow extra
> query parameters for use by the HC proxy. All the query parameters
> are going to the CoAP server. A non-default custom mapping function
> can be used to pass parameters to the HC proxy.
>
>  (In case that the query component intended for the CoAP server gets
> more complex (e.g. "?foo=4&bar=2") some percent encoding needs to be
> applied to make it all work. But we didn't look at that aspect in the
> I-D.) Using enhanced form also the example you gave of scheme as a
> parameter can be realized.
>
> regards Esko
>
> -----Original Message----- From: Oliver Kleine
> [mailto:[email-masked]] Sent: Tuesday, March 24, 2015
> 14:45 To: Dijk, Esko; [email-masked] Subject: Re: [core] HTTP/CoAP
> proxy setup
>
> Hello Esko,
>
> thanks a lot! That's quite similar to the solution I've been using
> since two years ago. The only differnce is that I did not encode the
> scheme in the path but as a query parameter such as
>
> I'm not sure if it is "allowed" to give query parameters to be
> handled by the proxy. But I could imagine that there may be diserable
> to add something like "do not use cached responses that are older
> than X" encoded as query parameter "?max-age-from-cache=X". That
> parameter is not intended to be forwarded to the CoAP server, i.e.
> included into the CoAP request but to be handled by the proxy.
>
> query parameters are generally to be added to the CoAP request. Is
> that correct?
>
> Thanks again and best, Oliver
>
>> reverse proxy case in draft-ietf-core-http-mapping-06 so that
>> there is never a need to enter a "coap://" URI inside a HTTP
>> request. So the case covered in draft-ietf-core-http-mapping-06 is
>> slightly different than you mentioned  - for example like this
>>
>> So the knowledge on which of coap/coaps scheme to use is encoded
>> by default inside the path. This should work from any web browser.
>>
>> Regards Esko
>>
>> -----Original Message----- From: core
>> [mailto:[email-masked]] On Behalf Of Oliver Kleine Sent:
>> Monday, March 23, 2015 17:51 To: [email-masked] Subject: [core]
>> HTTP/CoAP proxy setup
>>
>> Dear all,
>>
>> I'm currently trying to set up a scenario to test HTTP/CoAP
>> proxying using a forward proxy and a common HTTP Web Browser such
>> as Chrome or Firefox as a client. The current draft for HTTP/CoAP
>> Mapping at
>>
>> to define the target URL within the HTTP request. This implies
>> some CoAP scheme as the predefined target URL scheme. For
>> forwarding proxies in general the HTTP request is supposed to
>> contain the target URL in "absolute-form":
>>
>> configured to use a proxy. This seems to work fine with
>> http(s)-URLs but not for coap-URLs.
>>
>> I tried some addons like ProxyFoxy for Firefox and SwitchySharp
>> for Chrome but the URL pattern "coap*" leads to unexpected
>> behaviour. For e.g. Chrome a coap-URL in the address bar leads to
>> an unintended Google search for the given URL and not to the
>> intended HTTP request to the proxy configured to handle requests to
>> "coap*".
>>
>> but no solution. Is there any progress so far? Or, even better,
>> could someone recommend a proxy plugin which is able to properly
>> deal with the URL-pattern "coap://*"?
>>
>> law. The message is intended solely for the addressee(s). If you
>> are not the intended recipient, you are hereby notified that any
>> use, forwarding, dissemination, or reproduction of this message is
>> strictly prohibited and may be unlawful. If you are not the
>> intended recipient, please contact the sender by return e-mail and
>> destroy all copies of the original message.
>>
>
> --
>
> Oliver Kleine, M.Sc.
>
>

-- 

Oliver Kleine, M.Sc.

UNIVERSITÄT ZU LÜBECK
     INSTITUT FÜR TELEMATIK

     Ratzeburger Allee 160
     23538 Lübeck

     Tel +49 451 500 5396
     Fax +49 451 500 5382