Cannot GET service with name containing dot

Bug #1392568 reported by Shaunak Kashyap
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Poppy
Fix Released
High
Amit Gandhi

Bug Description

I created a service with name as "mywebsite.com" (using the example at http://docs.cloudcdn.apiary.io/#post-%2Fservices). The creation was successful (the response was 202).

The entry in the database looks like this:

    cqlsh:poppy> select service_name, origins, flavor_id from services ;

     service_name | origins | flavor_id
    ---------------+---------------------------------------------------------------------+-----------
     mywebsite.com | ['{"origin": "foobar.com", "port": 80, "rules": [], "ssl": false}'] | asia

    (1 rows)

Now when I try to retrieve this service via a GET request, I get a 404:

$ curl -v 'http://192.168.59.103:81/v1.0/services/mywebsite.com'
* About to connect() to 192.168.59.103 port 81 (#0)
* Trying 192.168.59.103...
* Adding handle: conn: 0x7fae44003a00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fae44003a00) send_pipe: 1, recv_pipe: 0
* Connected to 192.168.59.103 (192.168.59.103) port 81 (#0)
> GET /v1.0/services/mywebsite.com HTTP/1.1
> User-Agent: curl/7.30.0
> Host: 192.168.59.103:81
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: application/json; charset=UTF-8
< Content-Length: 47
<
* Connection #0 to host 192.168.59.103 left intact
{"message": "The resource could not be found."}

I even tried URL-encoding the dot in the name of the service, but I get the same error:

$ curl -v 'http://192.168.59.103:81/v1.0/services/mywebsite%2Ecom'
* About to connect() to 192.168.59.103 port 81 (#0)
* Trying 192.168.59.103...
* Adding handle: conn: 0x7ff241803a00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7ff241803a00) send_pipe: 1, recv_pipe: 0
* Connected to 192.168.59.103 (192.168.59.103) port 81 (#0)
> GET /v1.0/services/mywebsite%2Ecom HTTP/1.1
> User-Agent: curl/7.30.0
> Host: 192.168.59.103:81
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: application/json; charset=UTF-8
< Content-Length: 47
<
* Connection #0 to host 192.168.59.103 left intact
{"message": "The resource could not be found."}

Revision history for this message
Amit Gandhi (amit-gandhi) wrote :

you are missing the project id.

either add the header X-Project-ID with your project-id, or put it in the url, e.g. 'http://192.168.59.103:81/v1.0/5823616/services/mywebsite.com'

Changed in poppy:
status: New → Incomplete
Revision history for this message
Amit Gandhi (amit-gandhi) wrote :

I think the real bug here is that i can create a service without the projectid and that causes odd behaviour.

It creates a record with a project_id of "services". That then messes up the ability to perform a GET on a service.

Revision history for this message
Amit Gandhi (amit-gandhi) wrote :

Fixed with https://review.openstack.org/#/c/135082/

Please retest this to confirm if it is still an issue.

Changed in poppy:
importance: Undecided → Medium
assignee: nobody → Amit Gandhi (amit-gandhi)
milestone: none → kilo-1
status: Incomplete → Triaged
Changed in poppy:
assignee: Amit Gandhi (amit-gandhi) → Shaunak Kashyap (ycombinator-o)
milestone: kilo-1 → kilo-2
Revision history for this message
Shaunak Kashyap (ycombinator-o) wrote :

I am blocked on re-testing this by https://bugs.launchpad.net/poppy/+bug/1400395.

Revision history for this message
Amit Gandhi (amit-gandhi) wrote :

i am starting to see this bug also now.

For some reason, pecan is seeing the wrong content type come through when there is a dot in the service name (e.g. is sees type/x-msapplication instead of type/application-json

I am looking into this more to see if i can figure out why this is happening only when a dot is in the url.

Changed in poppy:
importance: Medium → High
assignee: Shaunak Kashyap (ycombinator-o) → Amit Gandhi (amit-gandhi)
Revision history for this message
Amit Gandhi (amit-gandhi) wrote :

it appears to be related to this pecan setting - http://pecan.readthedocs.org/en/latest/pecan_core.html
guess_content_type_from_ext – A boolean indicating if this project should use the extension in the URL for guessing the content type to return.

this explains why service names ending in .com would return a msapplication, and .au would return audio/basic as the content type

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to poppy (master)

Fix proposed to branch: master
Review: https://review.openstack.org/142487

Changed in poppy:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to poppy (master)

Reviewed: https://review.openstack.org/142487
Committed: https://git.openstack.org/cgit/stackforge/poppy/commit/?id=9292baff3b5d3edd7739541ecafa8ec36196ad12
Submitter: Jenkins
Branch: master

commit 9292baff3b5d3edd7739541ecafa8ec36196ad12
Author: amitgandhinz <email address hidden>
Date: Tue Dec 16 17:54:42 2014 -0500

    User can now get services where the service name has an extension

    For example, www.site.com would attempt to be an msapplication content type
    and www.site.com.au would attempt to be an audio/object content type

    Change-Id: I474fc523558a8c99ded656eff45f022ae6fb38ae
    Closes-Bug: 1392568

Changed in poppy:
status: In Progress → Fix Committed
Revision history for this message
Shaunak Kashyap (ycombinator-o) wrote :

I can confirm that this bug has been fixed now. Thanks!

Changed in poppy:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.