llHTTPRequest with Authorization Token

I am experimenting with the Google Data API with mixed results and wondered if any one could give me a spot of help.

I have managed to use the ClientLogin service and it correctly returns the keys.
In the API documentation it say

The problem is that I am not sure how to use that header information in subsequent HTTP Requests. I have been trying the following:

requestid = llHTTPRequest("http://spreadsheets.google.com/feeds/spreadsheets/private/full",[HTTP_METHOD,"GET","Authorization: GoogleLogin auth="+auth],"";

where auth is a string containing the Authorization key from the earlier step.
p.s. I did try URLEscape on the Authorisation header, still no luck.

It should return metadata about the users spreadsheets but instead it is returning a 404 status. I have a feeling that, despite the status being 404 rather than 401 or 403, it is something to do with the way I am handling the Authorization token, as I know there are valid spreadsheets in the account.

Any advise or suggestions would be greatly appreciated.

edit: I had to trim this post a lot as it was would not allow me to post the original, If anybody would like more info I can post specifics.

The list parameters has to be integer/string pairs, and currently, I'm afraid llHTTPRequest doesn't seem to support authorization:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=llHTTPRequest

Sorry I can't be of more help!

Would you believe there's no support for supplying headers with an HTTP request? Does anyone have any clue why?

Anyway, here's a JIRA issue: http://jira.secondlife.com/browse/SVC-563

It's hard to believe there are only 10 votes. If you find a different issue in the JIRA please post it here, I want to vote.

OK, Thanks Guys I voted, but I guess that is 2 days of wasted effort on my part "assuming" that the HTTP protocols would at least conform to the standards.

With no encryption, no authentication, no XML parser, limited packet sizes and no data storage and Linden Labs still want to pitch this as a business application platform?
I think it is only 10 (11 now) votes because the people who need that functionality see its absence as a good reason not to use SL for business and so don't bother to vote or even sign in

I think LSL as a language really hasn't had the power or memory capacity to cope with large volumes of data (until Mono, anyway), so there wasn't really any need for big complex features. In saying that, I doubt they are ever likely to let you edit the HTTP headers in whatever way you like, since that could open up a huge can of worms for security and reliability and so on.

There's other ways round it anyway, allowing you still to do plenty of stuff even for business applications (you just need to have a fairly ruthless approach to efficiency!). Instead of using generic standards, you can create your own bespoke data format which operates as a layer on top of HTTP, and implement your own security in with it. That's what we do in the Sloodle project (www.sloodle.org). We have a very rigid text-based format for a "status line" at the start of any data, and the subsequent line(s) follow similar layout guidelines, but the format is generally dependent on the task at hand, so as little parsing as possible is needed. Internal passwords are sent as HTTP parameters. It might not be a perfect solution, but it's usually sufficient.

12 votes...

Being able to add http-headers would allow us to use the «content-range: bytes...»-header, which would allow us to pull more data from a webpage than just the first 2048bytes.

But - as Pedro points out - this might be a worm-can-opener.... So we might never see this...

Looks like the door is not yet closed on replacing LSL then. I wonder if the .NET version of the GData Tools would run under this implementation of MONO. But I wont hold my breath waiting

I will have a go at writing a Google App Engine application as a gateway to the GData API's, but that means having to now learn Python too and for my simple application requirements it is rather an overkill, especially as I am not a professional developer nor have a potential revenue stream to make the time investment worthwhile.

That's the SL spirit!

Uh huh. You think I'm joking?

Can't you specify authorisation as part of the URL? Like this:
http://username:password@domain.com/page.php?

Or are you trying to do something different?

Something different, you log in as:

requestid = llHTTPRequest("https://www.google.com/accounts/ClientLogin",
[HTTP_METHOD, "POST",HTTP_MIMETYPE, "application/x-www-form-urlencoded"],
"accountType=HOSTED_OR_GOOGLE&Email=user@gmail.com&Passwd=userpassword&service=wise";

It then returns 3 Tokens in XML format, one of which is the Auth=Token, that must then be used in each HTTP request.

Ah, didn't realise the login type was Google's own kind, thought it was just based off the same authorisation you can place directly into the URL.

Could you use your own website to build the requests using input from a script? I know it's not ideal but it's likely all we can do for now =(

Yes, and that is exactly what I am trying to prevent
So far the only way around the data-storage problems have been to

a) send it to your own PC, via email or chat log, which is not to bad for archival information, but is difficult to retrieve.

b) store it in scripts and hope that the script is not directly or indirectly reset. Personally I like this method and have not yet lost any data in over 2 years, but it is limited to storage in the same object or region unless you can also guarantee that the object key will not change.

c) use a 3rd party data base over which you have little control, must trust the provider and hope that they will remain in business long after you are around to support your own scripts.

d) host your own web site with SQL etc. but have the cost of maintaining it and providing user support if you sell any scripts that use it.

But now that Google provide API's to Google Docs it makes sense to use them for SL storage as they are free, the platform is scalable and reliable and in all honesty I think Google will be around a lot longer than SL so I trust them with my data.

A while ago some one on this forum said "if you have learnt LSL you can learn a language like C++ or Java in a weekend", so I am putting it to the test, I have given myself a weekend to learn Python and the Google Apps Engine SDK to see if I can set up a gateway for LSL into Google Docs and possibly even use the Google database.

Wish me luck

Hehe, the C++ programmer in me is writhing at that quote! (Preprocessor commands, memory pointers/references, function overloading, object orientation, dynamic/static polymorphism, metaprogramming... ... I'll stop now...)

How'd you get on with Python? It's a bit of a weird language, but certainly very interesting to use. I especially like all the Monty Python references in the documentation!

Well I didn't reach my goal fully, but I did scratch the surface and get one or two simple programs running. I find it a fascinating language, although some of the data types have my mind spinning such as Lists of Tuples of lists and string vs text data types. I also find the syntax to be strange, having to use precise indentation rather than braces and punctuation to define code blocks.

One thing that I did learn is that I have a lot to learn, so I spent most of the weekend finding info and setting up a test environment. So far I have Python 2.5 and Idle installed, have a local HTTP server (the one written in python) running. have the GData API's and SDK installed and can use LSLEditor to talk to python or the locally hosted Google App and have them send data back to LSLEditor, so my whole development environment can work offline.

I also had to read up on HTTP so that I understood what I was trying to achieve as well as the GData API's so that I knew the headers and data types. I also spent time reading up on CGI and on XML so that I could understand what web servers are doing and what format the data was being returned in.

I now have a better understanding of what I need to do, an environment to do it in and the tools and basic knowledge to read and dissect Python libraries and functions and how to import what I need etc.

All in all it was a fun and rewarding exercise and, though I doubt I will have any production code running in the short term, I have certainly broadened my knowledge and discovered a whole new set of tools.

And being a Monty Python fan certainly helps to understand the humor hidden in the tutorials

hahaha... now that is funny! I'd love to know who said that.

I've given SIMILAR messages here and elsewhere, but I seriously doubt I would have included the, "in a weekend," bit, at least with the stated scope of learning.

So, at the risk of being accused of threadbumping, has anyone tried sending URL-encoded data to a Google spreadsheet using forms? I've been trying to do so without success.

The short form: I have an object in SL which tracks data, and I want to send that data to a Google spreadsheet. Since Google came out last September with a way to pre-fill forms (http://docs.google.com/support/bin/answer.py?hl=en&answer=160000) via URL-encoded data, I thought this would be perfect! Except for one thing: the form just pre-fills; it does not auto-Submit.

I tried to get it to auto-submit by constructing the URL and submitting it via POST, e.g.:

key submit_uuid = llHTTPRequest( "http://spreadsheets.google.com/viewform?hl=en&formkey=12345", [HTTP_MIMETYPE, "application/x-www-form-urlencoded", HTTP_METHOD, "POST"], "&entry_0=data0&entry_1=data1&entry_2=data2" )

What happens is that in the http_response event, the body that comes back contains the HTML form code for the pre-filled in form!

One way I *could* go is to have the object llOwnerSay the constructed URL and tell the user to click on that in their chat history, which would pop up the form and they could click on Submit. But that's... kludgy, and besides, they could then decide to alter the data.

So, if anyone here *has* managed to pass data to a Google spreadsheet via a form, I'd appreciate a hand with this.

Reynard Baroque
"If it's not baroque, fix it!"

maybe learn to use basic C++ syntax and commands.... although I think jscript is a more realistic goal (and with all the available commands to learn I still find new ones of those, or rediscover old ones)

Unfortunately, you cannot send HTTP Header data directly via LSL.
Google requires AuthSub Token's to be sent via the header.

The only way around it is to have a website that has PHP / Python that can process the token info. Or maybe use Google Appspot as a workaround.