Details
-
Sub-task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
Description
As of now the main s3g endpoint (such as http://localhost:9878) returns with HTTP 500 if it's opened from the browser.
The main endpoint is used to get all the available buckets, but amazon returns with a redirect IF the Authorization header is missing:
curl -v s3.us-east-2.amazonaws.com
* Trying 52.219.88.59...
* TCP_NODELAY set
* Connected to s3.us-east-2.amazonaws.com (52.219.88.59) port 80 (#0)
> GET / HTTP/1.1
> Host: s3.us-east-2.amazonaws.com
> User-Agent: curl/7.62.0
> Accept: */*
>
< HTTP/1.1 307 Temporary Redirect
< x-amz-id-2: fq8RXJdSlVo8PqidHaP8XXczMfLSEAt5Tm4JP98atilWRjalMvqtPa6mwq6rEIXz4cCPrPqJkO4=
< x-amz-request-id: 5C6ACE6D6FC273B9
< Date: Thu, 06 Dec 2018 11:16:36 GMT
< Location: https://aws.amazon.com/s3/
< Content-Length: 0
I propose to do the same for Ozone:
1.) If the authorization header is missing on the root URL, redirect to an internal page.
2.) Create an internal landing page at http://localhost:9878/_ozone with the following content:
a) A very short introduction to use the endpoint (with aws client)
b) The actual documentation of ozone (which is also included in the scm/om ui)
Note: we need an url schema which is not conflicting with the real REST requests. As the bucket and volume names should not contain underscore in ozone, we can use it to prefix all the urls:
- http://localhost:9878/_ozone --> landing page
- http://localhost:9878/_ozone/(css|js) --> required resources
- http://localhost:9878/_ozone/docs --> Documentation with the required resources.
Attachments
Attachments
Issue Links
- links to