Mailing-List: contact dev-help@deltacloud.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@deltacloud.apache.org
Date: Thu, 29 Mar 2012 12:28:25 +0000 (UTC)
From: "Marios Andreou (Commented) (JIRA)" <jira@apache.org>
To: dev@deltacloud.apache.org
Message-ID: 
 <848935230.32236.1333024105735.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <521589507.10001.1332533727287.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DTACLOUD-175) Executing "HEAD
 /api/buckets/:bucket_id/:blob_id - returns 200 OK but no user meta_data
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DTACLOUD-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241176#comment-13241176 ] 

Marios Andreou commented on DTACLOUD-175:
-----------------------------------------

Spent best part of today on this but am giving up for now for the sake of my sanity.

Notes:

-> cURL is generating the correct request. For some reason, HEAD /api/buckets/:bucket_name/:blob_name is actually hitting the route GET /api/buckets/:bucket_name/:blob_name

-> The issue is specific to the machine being tested... I couldn't recreate on my local machine using the same code (fresh clone of dc git repo on both). Also reinforced by the original comment above, assuming that the machine running deltalcoud-core-0.5.0-8 is not the same as this testing machine.

-> Interesting/weird behaviour: if you remove ALL the routes from server.rb (i.e. all 'collection :foo do' blocks) except buckets (and blob subcollection), the problem magically disappears. This would suggest an issue with Rabbit and subcollections, except the problem is not reproducible on other machines..?

-> tried the same request with telnet and got the same behaviour:

telnet 127.0.0.1 3001
HEAD /api/buckets/mariosanotherbucketohyeah/someshinynewblob?format=xml HTTP/1.1
Authorization: Basic <_THE_AUTH_BLOB_>
Host: localhost:3001
Accept: */*

HTTP/1.1 200 OK
Content-Type: application/xml
Server: Apache-Deltacloud/0.5.0
X-Runtime: 1.625874
X-XSS-Protection: 1; mode=block
X-Frame-Options: sameorigin
Content-Length: 679
Date: Thu, 29 Mar 2012 11:25:58 GMT
Connection: keep-alive

(correct response is 204 with blob metadata in the headers)

-> tried swapping sinatra 1.3.2 with 1.3.1 (matching what my machine is running) - no joy

-> testing machine: 

`uname -a`: Linux qe-blade-02.idm.lab.bos.redhat.com 3.3.0-4.fc16.x86_64 #1 SMP Tue Mar 20 18:05:40 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

`ruby -v`: ruby 1.8.7 (2011-12-28 patchlevel 357) [x86_64-linux]

gems: sinatra (1.3.1), thin (1.3.1), rack (1.4.1), rack-accept (0.4.4), rack-protection (1.2.0), rack-test (0.6.1), eventmachine (0.12.10), aws (2.5.6)

                
> Executing "HEAD /api/buckets/:bucket_id/:blob_id - returns 200 OK but no user meta_data
> ---------------------------------------------------------------------------------------
>
>                 Key: DTACLOUD-175
>                 URL: https://issues.apache.org/jira/browse/DTACLOUD-175
>             Project: DeltaCloud
>          Issue Type: Bug
>          Components: Server
>         Environment:  - Deltacloud git commit version 7e372dfca79c02a799046287e5936129216b781b - branch 'master' of https://git-wip-us.apache.org/repos/asf/deltacloud
>  - ec2 provider
>  - Fedora 16, RHEL 6.2
>            Reporter: Ronelle Landy
>            Assignee: Marios Andreou
>
> Using deltalcoud-core-0.5.0-8:
> (>> rpm -qa |grep deltacloud
> deltacloud-core-ec2-0.5.0-8.el6.noarch
> deltacloud-core-vsphere-0.5.0-8.el6.noarch
> rubygem-deltacloud-client-0.5.0-2.el6.noarch
> deltacloud-core-0.5.0-8.el6.noarch
> deltacloud-core-rhevm-0.5.0-8.el6.noarch)
> curl -i  -X HEAD --user "username:password" "http://ibm-x3200m3-01.rhts.eng.bos.redhat.com:3005/api/buckets/bucket-rlandy2/03222012blob6?format=xml"
> HTTP/1.1 204 No Content
> X-Runtime: 0.562315
> Server: Apache-Deltacloud/0.5.0
> X-Deltacloud-Blobmeta-version: 2.4
> X-Deltacloud-Blobmeta-name: myblob
> X-Deltacloud-Blobmeta-author: rlandy
> Date: Fri, 23 Mar 2012 20:06:18 GMT
> Connection: close
> Using deltacloud git commit version 7e372dfca79c02a799046287e5936129216b781b, no user meta_data is returned:
> curl -i  -X HEAD --user "username:password" "http://localhost:3009/api/buckets/bucket-rlandy2/03222012blob6?format=xml"HTTP/1.1 200 OK
> X-Runtime: 0.427717
> X-Frame-Options: sameorigin
> Date: Fri, 23 Mar 2012 20:07:45 GMT
> Content-Length: 457
> X-XSS-Protection: 1; mode=block
> Content-Type: application/xml
> Server: Apache-Deltacloud/0.5.0
> Connection: keep-alive
> curl: (18) transfer closed with 457 bytes remaining to read
> Log output copied below:
> == Info: About to connect() to localhost port 3009 (#0)
> == Info:   Trying 127.0.0.1... == Info: connected
> == Info: Connected to localhost (127.0.0.1) port 3009 (#0)
> == Info: Server auth using Basic with user '...'
> => Send header, 328 bytes (0x148)
> 0000: HEAD /api/buckets/bucket-rlandy2/03222012blob6?format=xml HTTP/1
> 0040: .1
> 0044: Authorization: Basic ...
> 0084: ...==
> 00af: User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7
> 00ef:  NSS/3.13.1.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> 0123: Host: localhost:3009
> 0139: Accept: */*
> 0146: 
> <= Recv header, 17 bytes (0x11)
> 0000: HTTP/1.1 200 OK
> <= Recv header, 21 bytes (0x15)
> 0000: X-Runtime: 0.393294
> <= Recv header, 29 bytes (0x1d)
> 0000: X-Frame-Options: sameorigin
> <= Recv header, 37 bytes (0x25)
> 0000: Date: Fri, 23 Mar 2012 20:10:27 GMT
> <= Recv header, 21 bytes (0x15)
> 0000: Content-Length: 457
> <= Recv header, 33 bytes (0x21)
> 0000: X-XSS-Protection: 1; mode=block
> <= Recv header, 31 bytes (0x1f)
> 0000: Content-Type: application/xml
> <= Recv header, 33 bytes (0x21)
> 0000: Server: Apache-Deltacloud/0.5.0
> <= Recv header, 24 bytes (0x18)
> 0000: Connection: keep-alive
> <= Recv header, 2 bytes (0x2)
> 0000: 
> <= Recv data, 0 bytes (0x0)
> == Info: transfer closed with 457 bytes remaining to read
> == Info: Closing connection #0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira