• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-2682
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Normal Normal
Assignee: Tess Linden
Reporter: Tao Takashi
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

OGP Beta: Agent Domain returns wrong content-type when retrieving a cap from the seed cap

Created: 23/Jul/08 10:19 AM   Updated: 25/Aug/08 10:16 PM
Return to search
Component/s: Interop - Agent Domain
Affects Version/s: None
Fix Version/s: None

Issue Links:
Relates

Linden Lab Issue ID: DEV-18292


 Description  « Hide
When trying to retrieve the "place_avatar" cap from the seed capability it returns the following:

Date: Wed, 23 Jul 2008 17:11:52 GMT
Content-Length: 275
Content-Type: text/html
<?xml version="1.0" ?><llsd><map><key>lastname</key><string>Magic</string><key>firstname</key><string>Zope</string><key>caps</key><map><key>place_avatar</key><string>https://agent0.aditi.lindenlab.com:12043/cap/71db5957-58da-11dd-8a92-005045bbae52</string></map></map></llsd>

The Content-Type header needs to be application/llsd+xml instead of text/html

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
[ Permlink | « Hide ]
Tess Linden added a comment - 23/Jul/08 05:52 PM
I get an error when I try to run the tests:

tess@station35:/var/tmp/tess/pyogp$ bin/test
Traceback (most recent call last):
File "/var/tmp/tess/pyogp/bin/test", line 44, in ?
zope.testing.testrunner.run([
File "/usr/lib/python2.3/site-packages/PIL/_init_.py", line 31, in run

File "/var/tmp/tess/pyogp/eggs/zope.testing-3.6.0-py2.3.egg/zope/testing/testrunner/runner.py", line 490
return sum(r.num_ran for r in results)
^
SyntaxError: invalid syntax


[ Permlink | « Hide ]
Tess Linden added a comment - 23/Jul/08 06:41 PM
I'm getting the correct content type when I curl it with the correct content type. After I log in, I use the place_avatar cap:

tess@station35:/var/tmp/tess/pyogp$ curl -H "Content-type: application/llsd+xml" -v -X "POST" -d "<llsd><map><key>reginlab.com:13000</string></map></llsd>" "https://agent1.aditi.lindenlab.com:12043/cap/bbfd338a-5920-11dd-bd94-0030488f1d92"

  • About to connect() to agent1.aditi.lindenlab.com port 12043
  • Trying 63.210.158.233... * connected
  • Connected to agent1.aditi.lindenlab.com (63.210.158.233) port 12043
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: none
  • SSL connection using AES256-SHA
  • Server certificate:
  • subject: /C=US/ST=California/L=San Francisco/O=Linden Lab, Inc./CN=*.aditi.lindenlab.com/emailAddress=root@lindenlab.com
  • start date: 2006-11-09 00:14:49 GMT
  • expire date: 2009-11-08 00:14:49 GMT
  • common name: *.aditi.lindenlab.com (matched)
  • issuer: /C=US/ST=California/L=San Francisco/O=Linden Lab, Inc./OU=Linden Lab Certificate Authority/CN=Linden Lab Certificate Authority/emailAddress=ca@lindenlab.com
  • SSL certificate verify ok.
    > POST /cap/bbfd338a-5920-11dd-bd94-0030488f1d92 HTTP/1.1
    User-Agent: curl/7.13.2 (i386-pc-linux-gnu) libcurl/7.13.2 OpenSSL/0.9.7e zlib/1.2.2 libidn/0.5.13
    Host: agent1.aditi.lindenlab.com:12043
    Pragma: no-cache
    Accept: /
    Content-type: application/llsd+xml
    Content-Length: 98

<llsd><map><key>region_url</key><string>http://sim1.vaak.lindenlab.com:13000</string></map></llsd>< HTTP/1.0 200 OK
< Date: Thu, 24 Jul 2008 01:36:43 GMT
< Content-Length: 689
< Content-Type: application/llsd+xml
< Server: BaseHTTP/0.3 Python/2.3.5

  • Closing connection #0
    <?xml version="1.0" ?><llsd><map><key>region_y</key><integer>256512</integer><key>region_x</key><integer>255488</integer><key>seed_capability</key><string>https://sim1.vaak.lindenlab.com:12043/cap/e4864ec1-ddc9-f9d6-63c5-b80b5390bf1a</string><key>region_id</key><uuid>31b166cf-9339-04b8-e186-f357724daae3</uuid><key>look_at</key><array><real>0.0</real><real>0.0</real><real>0.0</real></array><key>rez_avatar/rez</key><undef /><key>sim_access</key><string>PG</string><key>connect</key><boolean>true</boolean><key>sim_port</key><integer>13000</integer><key>position</key><array><real>0.0</real><real>0.0</real><real>0.0</real></array><key>sim_ip</key><string>8.4.131.62</string></map></llsd>

=======

After the test works, we can figure out why the llsd lib that the test is using didnt work.


[ Permlink | « Hide ]
Tao Takashi added a comment - 24/Jul/08 01:51 AM
Can you maybe test with Python 2.4 or up, it might be an issue with the Python version used. I think we defined the minimum requirement to be Python 2.4.

The problem in my case happenes not when using the place_avatar cap but when trying to retrieve it from the seed cap, so one step before that. But I will also check our code again.


[ Permlink | « Hide ]
Tess Linden added a comment - 24/Jul/08 02:53 PM
I'm running this on my mac with Python 2.5.1 and get this failure:

koolaid:pyogp tess$ python bootstrap.py

Creating directory '/Users/tess/pyogp/parts'.
Creating directory '/Users/tess/pyogp/eggs'.
Creating directory '/Users/tess/pyogp/develop-eggs'.
Generated script '/Users/tess/pyogp/bin/buildout'.
koolaid:pyogp tess$
koolaid:pyogp tess$ bin/buildout -v
Installing 'zc.buildout', 'setuptools'.
We have the best distribution that satisfies 'zc.buildout'.
Picked: zc.buildout = 1.1.0
We have the best distribution that satisfies 'setuptools'.
Picked: setuptools = 0.7a1dev-r0
Develop: '/Users/tess/pyogp/src/pyogp.lib.base'
Develop: '/Users/tess/pyogp/src/pyogp.testharness'
Traceback (most recent call last):
File "/var/folders/pL/pLD+ffZMGpay5PmakiKVt++++TI/Tmp/tmpGWLFyF", line 11, in <module>
execfile('/Users/tess/pyogp/src/pyogp.testharness')
IOError: [Errno 2] No such file or directory: '/Users/tess/pyogp/src/pyogp.testharness'
While:
Installing.
Processing develop directory '/Users/tess/pyogp/src/pyogp.testharness'.

An internal error occured due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
File "/private/var/folders/pL/pLD+ffZMGpay5PmakiKVt++++TI/Tmp/tmpmOr6SH/zc.buildout-1.1.0-py2.5.egg/zc/buildout/buildout.py", line 1472, in main
File "/private/var/folders/pL/pLD+ffZMGpay5PmakiKVt++++TI/Tmp/tmpmOr6SH/zc.buildout-1.1.0-py2.5.egg/zc/buildout/buildout.py", line 319, in install
File "/private/var/folders/pL/pLD+ffZMGpay5PmakiKVt++++TI/Tmp/tmpmOr6SH/zc.buildout-1.1.0-py2.5.egg/zc/buildout/buildout.py", line 551, in _develop
File "/private/var/folders/pL/pLD+ffZMGpay5PmakiKVt++++TI/Tmp/tmpmOr6SH/zc.buildout-1.1.0-py2.5.egg/zc/buildout/easy_install.py", line 866, in develop
AssertionError


[ Permlink | « Hide ]
Tess Linden added a comment - 25/Jul/08 01:43 PM
I've now gotten a working pyogp checkout! w00t

[ Permlink | « Hide ]
Tao Takashi added a comment - 29/Jul/08 03:07 AM
Great Any news on this bug though? I would like to prevent adding some workaround to the library to make it work again.

[ Permlink | « Hide ]
Tess Linden added a comment - 29/Jul/08 10:07 AM - edited
I'm also getting the correct content type on the seed cap:

[13:53:12] enus@station18:~/svn/pyogp/libdev$ curl -kH "Content-type: application/llsd+xml" -v -X "POST" -d "<llsd><map><key><string>caps</string></key><map></map></map></llsd>" https://agent0.aditi.lindenlab.com:12043/cap/a2d8d711-5dae-11dd-8b1e-005045bbae52

  • About to connect() to agent0.aditi.lindenlab.com port 12043
  • Trying 8.4.131.23... * connected
  • Connected to agent0.aditi.lindenlab.com (8.4.131.23) port 12043
  • successfully set certificate verify locations:
  • CAfile: /usr/share/curl/curl-ca-bundle.crt
    CApath: none
  • SSL connection using AES256-SHA
  • Server certificate:
  • subject: /C=US/ST=California/L=San Francisco/O=Linden Lab, Inc./CN=*.aditi.lindenlab.com/emailAddress=root@lindenlab.com
  • start date: 2006-11-09 00:14:49 GMT
  • expire date: 2009-11-08 00:14:49 GMT
  • common name: *.aditi.lindenlab.com (matched)
  • issuer: /C=US/ST=California/L=San Francisco/O=Linden Lab, Inc./OU=Linden Lab Certificate Authority/CN=Linden Lab Certificate Authority/emailAddress=ca@lindenlab.com
  • SSL certificate verify result: error number 1 (20), continuing anyway.
    > POST /cap/a2d8d711-5dae-11dd-8b1e-005045bbae52 HTTP/1.1
    User-Agent: curl/7.13.2 (i386-pc-linux-gnu) libcurl/7.13.2 OpenSSL/0.9.7e zlib/1.2.2 libidn/0.5.13
    Host: agent0.aditi.lindenlab.com:12043
    Pragma: no-cache
    Accept: /
    Content-type: application/llsd+xml
    Content-Length: 67

<llsd><map><key><string>caps</string></key><map></map></map></llsd>< HTTP/1.0 200 OK
< Date: Tue, 29 Jul 2008 20:54:02 GMT
< Content-Length: 44
< Content-Type: application/llsd+xml
< Server: BaseHTTP/0.3 Python/2.3.5

  • Closing connection #0
    <?xml version="1.0" ?><llsd><undef /></llsd>

=========================
When I ran the tests in pyogp, they all passed correctly. The instructions on the bottom of http://wiki.secondlife.com/wiki/Pyogp/Client_Lib/The_Development_Sandbox should be moved to http://wiki.secondlife.com/wiki/Pyogp/Client_Lib/testing for completeness and linked... going to try running the test suite to see failure


[ Permlink | « Hide ]
Tess Linden added a comment - 29/Jul/08 10:55 AM
I printed out self.public_url inside caps.py in order to debug the error, and I got http://127.0.0.1:12345/seed_cap_wrong_content_type. Is this hosted somewhere locally? How is that hooked up to test real seed caps?

[ Permlink | « Hide ]
Tao Takashi added a comment - 30/Jul/08 08:25 AM
If you run the tests they will setup a local mockup test server. This is a simple WSGI App which does not run in a server but gets called directly by the mockup network layer. The host:port part gets removed and the path is passed to the wsgi app.

When you run bin/login there actually should be some other ouput.


[ Permlink | « Hide ]
enus linden added a comment - 01/Aug/08 12:02 PM
I've also seen "application/xml" returned from the POST to the rez_avatar/* caps. The OGP documentation needs to detail what the expected content-type is in the response...

[ Permlink | « Hide ]
Tess Linden added a comment - 01/Aug/08 12:13 PM
application/xml is incorrect. The OGP does detail the expected content-type: https://wiki.secondlife.com/wiki/Open_Grid_Protocol#Serialization
I'm now working on this bug again... sorry for the interruption.

[ Permlink | « Hide ]
Tess Linden added a comment - 11/Aug/08 06:02 PM
Turns out curl automatically inserts a "/" Accept header, which makes this work. Here's the patch to fix this:

Index: src/pyogp.lib.base/pyogp/lib/base/caps.py
===================================================================
— src/pyogp.lib.base/pyogp/lib/base/caps.py (revision 1030)
+++ src/pyogp.lib.base/pyogp/lib/base/caps.py (working copy)
@@ -54,7 +54,7 @@
content_type = serializer.content_type
serialized_payload = serializer.serialize()

  • headers = {"Content-type" : content_type}
    + headers = {"Content-type" : content_type, "Accept" : "*/*"}
    headers.update(custom_headers) # give the user the ability to add headers
  1. TODO: better errorhandling with own exceptions
Powered by Atlassian JIRA the Professional Issue Tracker. (Enterprise Edition, Version: 3.13.2-#335) - Bug/feature request - Atlassian news - Contact Administrators