support root-based web service URL's

Bug #520269 reported by Robert Collins on 2010-02-11
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Eucalyptus
Confirmed
Wishlist
chris grzegorczyk
eucalyptus (Ubuntu)
Wishlist
Unassigned

Bug Description

Eucalyptus web services are rooted differently to Amazons and this forces more complex configuration for users and third part developers.

Specifically, the amazon EC2 api is at /, likewise the S3 api. For Eucalyptus it is at /services/Eucalyptus and /services/Walrus.

The actual API urls under these base paths are identical, and discrete (I think, may need to double check): its possible to map urls such that both web services are rooted at /, and do not conflict with each other. As per the port 80 bug this should be possible via apache rules combined with eucalyptus knowing that it is being accessed at /.

Making this the same would remove two configuration options / code changes from third party developers wanting to support UEC.

chris grzegorczyk (chris-grze) wrote :

I think you are refering to the "Host" header in HTTP as a way of co-locating multiple services. In the context of the current Eucalyptus system this isn't possible to support without the use of the DNS service. For example, virtual bucket hosting in S3 already works this way when DNS is enabled and configured correctly (e.g., http://bucket_name.eucalyptus_domain_name/). Adding support for this is likely when/if DNS-enabled becomes the standard installation mode.

cheers,
chris

Changed in eucalyptus:
assignee: nobody → chris grzegorczyk (chris-grze)
status: New → Won't Fix
importance: Undecided → Wishlist
status: Won't Fix → Confirmed
chris grzegorczyk (chris-grze) wrote :

Correct: the virtual bucket URL should be: http://bucket_name.walrus.eucalyptus_domain_name/

Robert Collins (lifeless) wrote :

Well I mean for both EC2 and S3, not just S3. Should I file separate bugs? [I had been thinking this was just a rewritemap issue..]

Robert Collins (lifeless) wrote :

(Oh, and I'm not referring to the use of Host headers).

Scott Moser (smoser) on 2010-02-11
Changed in eucalyptus (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
Scott Moser (smoser) on 2010-02-11
Changed in eucalyptus (Ubuntu):
importance: Low → Wishlist
chris grzegorczyk (chris-grze) wrote :

Currently there is no way that I can see to implement this support without either: the use of the Host header (which requires DNS support), or deviating from the API spec (which would break compatibility and require support from client tools).

thanks.
chris

Kohsuke Kawaguchi (kk-kohsuke) wrote :

SOAP requests for S3 and EC2 use different namespace URIs, so it's quite possible to have both services served at the same URL, without the Host header. You just need to look at the namespace URI of the body.

chris grzegorczyk (chris-grze) wrote :

@6: Eucalyptus also handles Query and REST requests along with some less well-defined HTTP requests (e.g., form POST uploads). The decision on which path the web services stack takes when parsing a request is made solely based on the contents of the HTTP start-line and headers. This is primarily because consuming the message body is not feasible in some cases. In the absence of a service path or Host header/DNS info there is not enough information to determine the destination of a request. For these reasons using SOAP namespaces is not a sufficient approach.

With respect to the Host header, from the HTTP/1.1 RFC: "A client MUST include a Host header field in all HTTP/1.1 request messages". Thus, requiring use of DNS in order to provide virtual hosting seems reasonable and sufficient. A more thorough discussion of related topics can be found in the apache vhost documentation (n.b. some of the limitations do not apply to Eucalyptus): http://httpd.apache.org/docs/1.3/vhosts/

cheers.
chris

Andy Grimm (agrimm) wrote :

This issue is now being tracked upstream at http://eucalyptus.atlassian.net/browse/EUCA-2679

Please watch that issue for further updates.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers