[core] HTTP/CoAP proxy setup

[Oliver Kleine]

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 [phone]
Fax [phone]
***@itm.uni-luebeck.de

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

[Dijk, Esko]

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:core-***@ietf.org] On Behalf Of Oliver Kleine
Sent: Monday, March 23, 2015 17:51
To: ***@ietf.org
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

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 [phone]
Fax [phone]
***@itm.uni-luebeck.de

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


________________________________
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]

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

Post by Dijk, Esko
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
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
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
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
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*".
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
https://www.itm.uni-luebeck.de/people/kleine
________________________________ 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 [phone]
Fax [phone]
***@itm.uni-luebeck.de

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

[Dijk, Esko]

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:***@itm.uni-luebeck.de]
Sent: Tuesday, March 24, 2015 14:45
To: Dijk, Esko; ***@ietf.org
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

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

Post by Dijk, Esko
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
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
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
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
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*".
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
https://www.itm.uni-luebeck.de/people/kleine
________________________________ 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 [phone]
Fax [phone]
***@itm.uni-luebeck.de

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


________________________________
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]

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

Post by Dijk, Esko
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.
{+s}://{+hp}/{+p}?q={+q}
coaps://s.example.com/light?on
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
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
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

Post by Dijk, Esko
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
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
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
https://tools.ietf.org/html/draft-ietf-core-http-mapping-06
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
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*".
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 [phone] Fax [phone]
https://www.itm.uni-luebeck.de/people/kleine
________________________________ 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
https://www.itm.uni-luebeck.de/people/kleine
________________________________ 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 [phone]
Fax [phone]
***@itm.uni-luebeck.de

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

[Klaus Hartke]

Hi Oliver!

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