Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 340065

Summary:	[sites] Remote URLs are not really proxied
Product:	[ECD] Orion	Reporter:	Mark Macdonald <mamacdon>
Component:	Client	Assignee:	Mark Macdonald <mamacdon>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	0.2
Target Milestone:	0.2
Hardware:	PC
OS:	Windows 7
See Also:	http://code.google.com/p/js-test-driver/issues/detail?id=233
Whiteboard:

Description Mark Macdonald

2011-03-15 13:35:55 EDT

Orion 0.2M6

When you're editing a site, you can add a site path that maps to a remote URL, for example "/dojo.js" to "http://o.aolcdn.com/dojo/1.5/dojo/dojo.xd.js".

When a request is made for /dojo.js on your launched site, Orion essentially just does a simple GET on the remote URL and returns the response. Request/response headers are not forwarded between the client and the remote site. This is sometimes sufficient for a simple case like fetching a .js file from a CDN, but it doesn't allow for more interesting cases.

For example, you can't pass credentials to a remote URL that requires authentication, you can't use methods other than GET, and the remote server can't do any content negotiation based on the client's Accept- headers.

Instead it should work as a true web proxy. The request/response should not be modified beyond what is necessary (see [1]).

[1] http://tools.ietf.org/html/rfc2616#section-8.1.3

Comment 1 Mark Macdonald

2011-03-23 15:06:37 EDT

Using a (partial) fix for this, I've managed to get Orion-in-Orion hosting to work: the orion.client.core and orion.client.editor bundles are served from my Orion workspace, and other requests pass through to the running Orion server. So when I go to 127.0.0.2 I log in to my "real" Orion server, but the client-side JS UI code I get is the code that I'm developing.

The upshot is that I can self-host, but fall back to the "real" Orion when I need to recover from a wrecked JS environment.

However, there are some strange interactions when proxying the authentication process that I don't totally understand yet, and I've had to tweak the auth code to avoid them. It's probably an issue on my side.

One other problem is due to a limitation with the current site hosting support, which is that each "mount at" path can only point to 1 workspace path (or remote URL). It's a problem because a path like "/js" on an Orion server needs content from several different workspace locations (eg. the git bundle and the core bundle).

Comment 2 Mark Macdonald

2011-03-31 17:45:52 EDT

> However, there are some strange interactions when proxying the authentication
> process that I don't totally understand yet, and I've had to tweak the auth
> code to avoid them. It's probably an issue on my side.

Fixed this; apparently Dojo has a habit of sending GET requests with Content-Type headers, which is not good HTTP practice. This was confusing the proxy into making POST requests, which then failed.

However, there's another problem which didn't occur to me until now. The proxied responses we get back from the real server (localhost:8080) contain the URLs of resources on the real server (eg. localhost:8080/workspace/A). These resources are fetchable from client code running on the hosted server (127.0.0.2:8080) due to same-domain restrictions.

Comment 3 Mark Macdonald

2011-04-01 10:49:33 EDT

(In reply to comment #2)
> These resources are fetchable from client code running on the hosted server
> (127.0.0.2:8080) due to same-domain restrictions.

*NOT* fetchable

Comment 4 Mark Macdonald

2011-04-01 14:56:58 EDT

Now remote URLs are proxied with headers intact.

http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=b3374dea1d38d62142f024c4f4e812ab90a3e0f6

Comment 5 Mark Macdonald

2011-04-01 14:57:54 EDT

I will open separate bugs for the issue mentioned in Comment 1 (the overloading of paths on the Orion server) and Comment 2 (the crossdomain issue with resources).