| Summary: | Self-hosted site launching not working on orion.eclipse.org | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | John Arthorne <john.arthorne> |
| Component: | Client | Assignee: | Project Inbox <e4.orion-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bokowski, bokowski, mamacdon, susan |
| Version: | 0.2 | ||
| Target Milestone: | 0.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
John Arthorne
The server is essentially running an infinite loop of connections to itself.
Suppose you launch a self-hosting site at 127.0.0.2:8080. Then you access some Orion API path through it, say 127.0.0.2:8080/git.
- Since /git is part of our self-hosting config, it gets proxied to localhost:8080/git.
- However, the proxy implementation currently preserves the original "Host: 127.0.0.2" header from the first request.
- So we get a connection to localhost, but with the request claiming to be for 127.0.0.2.
- Orion sees that 127.0.0.2 is a running site, and starts the dance all over again.
I think the answer here is not to forward the Host header; instead it should be set based on the destination URL ("localhost" in this example). On top of that, forwarding a request to another hosted site shouldn't be allowed, or you run the risk of mutually recursive site definitions...
Why did this fail on orion.eclipse.org but worked on 127.0.0.1/2 (at least on my Mac)? I implemented the change I described to the "host" header treatment in Comment 1. It fixes the server hang when using a self-hosting set up. http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=646da906e2a9ae5093c323b0702da3e51b37bfb5 (In reply to comment #3) Also released a follow-up change that makes the proxy use the Max-Forwards header [1] to avoid getting stuck in infinite loops of proxied requests: http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=9bbef34ac89984549bf6e2728076a7718439d482 [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.31 This has been fixed, hasn't it? Yep. |