Child pages
  • Proxy Server Resource Provider
Skip to end of metadata
Go to start of metadata

Proxy Server Resource Provider

Status: DRAFT
Created: 10. January 2014
Author: fmeschbe
Issue: ---

Sketch

  • Request Forwarding
  • Pluggable Transport Protocol proxying: Requests to Sling are always HTTP based; proxied requests may be HTTP, FTP, or others.
  • Pluggable Request and Response translation: Input requests can be translated to SOAP requests with responses translated back according to expected formats such as JSON, XML, HTML, etc.
  • Request URL mapping to proxied request URL (e.g. using URL templates)
  • Configuration defined in the repository for ResourceProvider services:
    • Resource Type indicating Proxy root; e.g. sling:resourceType = proxy
    • Proxy URL; e.g. proxyUrl=http://the.target.com
    • etc
  • ProxyResourceProvider controller registers ResourceProvider services based on the proxy configurations with the respective root addresses.
  • Example: ResourceProvider registered at /proxy
    • proxyUtl=http://the.target.com
    • Map /proxy.html ==> http://the.target.com/
    • Map /proxy/foo.html ==> http://the.target.com/foo
  • No labels

3 Comments

  1. Looks interesting. Some things to consider:

    • Security - what if the target requires authentication?
    • Caching - can we cache the target resources using some configurable TTL?

    I'm not sure about the ResourceProvider definitions being in the repository. Shouldn't these just be factory components?

    1. Right Security would have to be considered (not really eager to store credentials in the repository, though). And caching certainly is one optimization we have to do.

      Having factory configuration would certainly make it easier to update etc. Having it in the repository would indicate the "root" node in the repository where this hangs out. Yet, of course, we could as well generate such a marker node on demand when the configuration is created.

  2. Just whiteboarding a node structure to define a proxy spec.