How to deal with urls when working behind load balancers, proxy and BFF.
24 views
Skip to first unread message
Gervais Blaise
Dec 7, 2017, 3:46:16 PM12/7/17
to Hypermedia Web
Hello there,
I would like to build an hypermedia api (Siren) for a product that run behind different kind of appliances. The frontend will be an Angular app, running on the client side. A request "GET /api/resource, Host:acme.com" sent from the client will pass trough our security appliances and then a load balancer that will forward the request to one of the nodes "GET /api/resource, Host:node1.acme.com".
"node1.acme.com" host our backend-for-frontend, that will in his turn send a similar request "GET /resource, Host:192.168.0.1:8080". The response will contains a link "{self: http://192.168.0.1:8080/resource}" and this one will move up to the chain until the client. But at the client side "192.168.0.1:8080" is not the same and will never be accessible from the outside.
So, my question is, how can we rewrite all the possibles urls that are in one hypermedia response when the server that render it is behind different kind of routers ?
It seems that the Http headers X-Forwarded-For or Fowarded can be used for that but it is not clear on how to use them.
For the BFF I may be able to replace all urls starting with the value of Host by the value of Fowarded. But for the load balancer and other appliances I have no clues. Does that means that our infrastructure may be a blocking point in implementing an hypermedia api ?
Thanks a lot for your help
I would like to build an hypermedia api (Siren) for a product that run behind different kind of appliances. The frontend will be an Angular app, running on the client side. A request "GET /api/resource, Host:acme.com" sent from the client will pass trough our security appliances and then a load balancer that will forward the request to one of the nodes "GET /api/resource, Host:node1.acme.com".
"node1.acme.com" host our backend-for-frontend, that will in his turn send a similar request "GET /resource, Host:192.168.0.1:8080". The response will contains a link "{self: http://192.168.0.1:8080/resource}" and this one will move up to the chain until the client. But at the client side "192.168.0.1:8080" is not the same and will never be accessible from the outside.
So, my question is, how can we rewrite all the possibles urls that are in one hypermedia response when the server that render it is behind different kind of routers ?
It seems that the Http headers X-Forwarded-For or Fowarded can be used for that but it is not clear on how to use them.
For the BFF I may be able to replace all urls starting with the value of Host by the value of Fowarded. But for the load balancer and other appliances I have no clues. Does that means that our infrastructure may be a blocking point in implementing an hypermedia api ?
Thanks a lot for your help
Peter Oostwoud-Sibiryak
Dec 8, 2017, 2:01:30 AM12/8/17
to Hypermedia Web
Hi Gervais,
We are using the key/value store option of Consul to store the address of the gateway. Not as "pure" as using headers pwrhaps, but works like a charm!
Hth, cheers,
Peter
mca
Dec 8, 2017, 3:16:07 AM12/8/17
to hyperme...@googlegroups.com
it is a good practice/pattern to continue to ship the full context (original requested URL and headers) through all the layers of the system. this carries *context* which can be used to re-build things like URLs, content-types, etc.
--
You received this message because you are subscribed to the Google Groups "Hypermedia Web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hypermedia-web+unsubscribe@googlegroups.com.
To post to this group, send email to hypermedia-web@googlegroups.com.
Visit this group at https://groups.google.com/group/hypermedia-web.
For more options, visit https://groups.google.com/d/optout.
Blaise Gervais
Dec 8, 2017, 7:14:49 AM12/8/17
to hyperme...@googlegroups.com
Do you mean that my client must be responsible to rewrite the link ? (!)
Le ven. 8 déc. 2017 à 09:16, mca <m...@amundsen.com> a écrit :
it is a good practice/pattern to continue to ship the full context (original requested URL and headers) through all the layers of the system. this carries *context* which can be used to re-build things like URLs, content-types, etc.On Fri, Dec 8, 2017 at 6:01 PM, Peter Oostwoud-Sibiryak <poos...@gmail.com> wrote:Hi Gervais,
We are using the key/value store option of Consul to store the address of the gateway. Not as "pure" as using headers pwrhaps, but works like a charm!
Hth, cheers,
Peter
--
You received this message because you are subscribed to the Google Groups "Hypermedia Web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hypermedia-we...@googlegroups.com.
To post to this group, send email to hyperme...@googlegroups.com.
Visit this group at https://groups.google.com/group/hypermedia-web.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "Hypermedia Web" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hypermedia-web/P8QDvlsDwe0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hypermedia-we...@googlegroups.com.
To post to this group, send email to hyperme...@googlegroups.com.
mca
Dec 8, 2017, 8:29:36 AM12/8/17
to hyperme...@googlegroups.com
nope.
On Fri, Dec 8, 2017 at 11:14 PM, Blaise Gervais <gerv...@gmail.com> wrote:
Do you mean that my client must be responsible to rewrite the link ? (!)
Le ven. 8 déc. 2017 à 09:16, mca <m...@amundsen.com> a écrit :
it is a good practice/pattern to continue to ship the full context (original requested URL and headers) through all the layers of the system. this carries *context* which can be used to re-build things like URLs, content-types, etc.On Fri, Dec 8, 2017 at 6:01 PM, Peter Oostwoud-Sibiryak <poos...@gmail.com> wrote:Hi Gervais,
We are using the key/value store option of Consul to store the address of the gateway. Not as "pure" as using headers pwrhaps, but works like a charm!
Hth, cheers,
Peter
--
You received this message because you are subscribed to the Google Groups "Hypermedia Web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hypermedia-web+unsubscribe@googlegroups.com.
To post to this group, send email to hypermedia-web@googlegroups.com.
Visit this group at https://groups.google.com/group/hypermedia-web.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "Hypermedia Web" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hypermedia-web/P8QDvlsDwe0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hypermedia-web+unsubscribe@googlegroups.com.
To post to this group, send email to hypermedia-web@googlegroups.com.
Visit this group at https://groups.google.com/group/hypermedia-web.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Hypermedia Web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hypermedia-web+unsubscribe@googlegroups.com.
To post to this group, send email to hypermedia-web@googlegroups.com.
Martynas Jusevičius
Dec 8, 2017, 2:35:25 PM12/8/17
to hyperme...@googlegroups.com
It has nothing to do with hypermedia. It looks like your proxy is non-conformant:
https://www.w3.org/TR/ct-guidelines/#sec-altering-header-values
https://www.w3.org/TR/ct-guidelines/#sec-altering-header-values
To unsubscribe from this group and stop receiving emails from it, send an email to hypermedia-we...@googlegroups.com.
To post to this group, send email to hyperme...@googlegroups.com.
Visit this group at https://groups.google.com/group/hypermedia-web.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "Hypermedia Web" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hypermedia-web/P8QDvlsDwe0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hypermedia-we...@googlegroups.com.
To post to this group, send email to hyperme...@googlegroups.com.
Visit this group at https://groups.google.com/group/hypermedia-web.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Hypermedia Web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hypermedia-we...@googlegroups.com.
To post to this group, send email to hyperme...@googlegroups.com.
Visit this group at https://groups.google.com/group/hypermedia-web.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Hypermedia Web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hypermedia-we...@googlegroups.com.
To post to this group, send email to hyperme...@googlegroups.com.
Blaise Gervais
Dec 8, 2017, 2:51:45 PM12/8/17
to hyperme...@googlegroups.com
Ok. Thanks, this is definitely interesting. However I still don't know how and what has to update the body of a response in order to replace internal urls by public ones.
What should I do to have urls that are valid and usable for the client returned to it ?
What should I do to have urls that are valid and usable for the client returned to it ?
Asbjørn Ulsberg
Dec 8, 2017, 6:28:39 PM12/8/17
to hyperme...@googlegroups.com
Your best option is to have all intermediaries (reverse proxies, load balancers, etc.) add (or forward) an RFC 7239 “Forwarded” header to the request going to the origin server, like so:
Forwarded: for=82.115.151.177; host=acme.com; proto=https
Each intermediary can append its own set of attributes corresponding to its knowledge. The first set of attributes (separated by a comma) represents the server receiving the request from the client.
When the origin server receives this header, all URLs it builds and puts in its HTTP body can use the “acme.com” host name and “https” protocol, even though the request received by the origin server might have come through node1.acme.com and on a regular, unencrypted HTTP connection.
--
Asbjørn Ulsberg -=|=- asb...@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»
Blaise Gervais
Dec 9, 2017, 1:57:28 AM12/9/17
to hyperme...@googlegroups.com
Ok got it. I have to use the first ˋForwarded` value to build my URL. I will give it a try this week.
Thanks a lot Asbjørn.
Thanks a lot Asbjørn.
Jeff Michaud
Dec 23, 2017, 2:43:37 PM12/23/17
to Hypermedia Web
Hello Gervais,
If you have that option too, you can use relative root urls http://ifyoucodeittheywill.com/2009/03/absolute-relative-and-root-relative-urls/ which abstracts a URL's authority (i.e. a service doesn't care about the authority (this is provided via HTTP headers), only it's own internal URL structure.
This is how the HCLI service hosted on http://hcli.io is setup: https://hcli.io/hal/#/hcli-webapp/cli/jsonf?command=jsonf
Regards
Jeff Michaud
If you have that option too, you can use relative root urls http://ifyoucodeittheywill.com/2009/03/absolute-relative-and-root-relative-urls/ which abstracts a URL's authority (i.e. a service doesn't care about the authority (this is provided via HTTP headers), only it's own internal URL structure.
This is how the HCLI service hosted on http://hcli.io is setup: https://hcli.io/hal/#/hcli-webapp/cli/jsonf?command=jsonf
Regards
Jeff Michaud
Reply all
Reply to author
Forward
0 new messages