Dynamic DNS service for HTTP-IN via Google App Engine

Great work Darien. As for the script archive, you might want to make a page for it on the wiki.

Well this blows. Me and my business partner just put in alot of work to make a system like this that was very low cost to use... hoping it would help us survive the recession. Guess we just got owned.

There is no failure: Only more data.

Great work, Darien =)

Thanks

I'll consider putting it on the wiki, but it may take me awhile to do.


And this doesn't preclude anyone from making their own serivce. It's very basic and I wouldn't be surprised if people don't want to hassle of setting it up and maintaining it. A good service that's easy to use and has the magic ingredient of Good Customer Service can still have a place.

I was having no luck at all getting it to forward the GET variables to the redirect page.. it almost did but not quite? if for example i sent

myblahblah.appspot.com/my_service/?red=blue

it gets an internal server error because it strips a / out of the redirected URL

ie; http://sim7434.agni.lindenlab.com:12046/cap/somekey?red=blue

so...

i changed the line:

self.redirect(urllib.unquote(record.url)+'?'+self.request.query_string) # redirect to the HTTP-IN URL with arugments

to

self.redirect(urllib.unquote(record.url)+'/?'+self.request.query_string) # redirect to the HTTP-IN URL with arugments

and it now works fine for me..

now, I make no claim that this is the right thing to do.. but it did make it work for me?...

cheers
non

I tried my original code, it works fine. I think it's all in how you store the URL.

Do you store your URL as "http://sim7434.agni.lindenlab.com:12046/cap/somekey"
or as: "http://sim7434.agni.lindenlab.com:12046/cap/somekey/" ?

I think in my coding I expected people to do it the second way. But if you do it the first way, then yes, you could do the change you mentioned.

The reason for this is, adding a slash on the end like LL requires is a bit odd/non-standard (dare I say I consider it a bug?). It would break things for anyone using this service for non-SL purposes.

To see what I mean, try these two links:

/348/1.html
/348/1.html

So I think the code must be neutral about supporting this abberation, it's up to the coder to handle any special considerations when storing a URL. Your fix isn't wrong, but I won't be putting it into the standard codebase. Thanks

I have a GNS system I made a while back for XML-RPC/email resolutions; I am updating it to support http-in cap urls, too. I plan on offering it as a fee-based service as well.

The fact that this and other "free" services exist doesn't bother me, nor should it deter you. There are many people who aren't technically savvy enough to get it working, or don't want to spend the time to do it when they can simply pay a small fee to have someone else make it easy for them. There are also plenty of people who only value something they pay for, expecting a certain level of service for their money. Those who provide such won't have any problem getting customers.

In short, just because there are "free" alternatives doesn't "kill the market" for "pay" options. In the end, nothing is ever truly "free"; everyone ends up paying for it in some way.

thanks for your explanation it makes a lot of sense and most of all thanks for providing this code...

cheers
nonnatus

The trailing slash is not an error on LL's part.

To use the forum example:
/348/1.html references the resource (file) named forumdisplay.php, in the forums.secondlife.com/ path (folder).

/348/1.html references the forums.secondlife.com/forumdisplay.php/ path (folder). Depending on context, convention would be to either present a directory listing, or to access a default resource.

They are really addressing two entirely different locations on the server.
The caps address you get from a llRequestURL is a *path* to a place on the server which happens to be handled by your prim; it is not an address to your prim as a specific resource.
This allows you to let your prim function as full web server and do things like http://http://sim7434.agni.lindenlab.com:12046/cap/somekey/admin/myspecificfunction

But it shouldn't require the slash to add parameters. It may not be an address, but it *functions* as one, and allows parameters as if it was one. So again, I have to say it's not consistent with the rest of the Internet.

Removing the need for the slash when making a GET request wouldn't prevent doing http://sim7434.agni.lindenlab.com:12046/cap/somekey/admin/myspecificfunction as you could just simply add the slash when addressing a subdirectory. So I dont' see that it would be wrong to do so. I know it's requirement throws many people, it's been complained about a number of times during HTTP-IN development, and it's not consistent with how most GET requests are formatted around the web.

In any event, the code won't be adding a slash, that would be bad for other uses as I outlined. Thanks

I think the intent is that you have a verb there, leaving that off and making the verb a named parameter doesn't save you anything, it wastes the space used by the name.

Again, no.
http://sim7434.agni.lindenlab.com:12046/cap/somekey?parameters is trying to send parameters to the somekey *file* in the cap *folder*. And it doesn't exist.

http://sim7434.agni.lindenlab.com:12046/cap/somekey/?parameters is sending parameters to the default file in the somekey folder.

That is by specification of how URLs work. That this forum apparently happens to accept both is flat out an error, by spec.

ETA:

While the URLs would end up looking the same, your *server resource* would pull a confusing double-duty as both a file and a directory, which doesn't really make sense, especially not if you're trying to actually obey HTTP specs (and do REST-style applications).

(I think most of the confusion comes from the fact that it's quite rare to send parameters to a default file. You almost always want to send it to a specifically named resource, so you rarely end up with the need for the /? notation).

Actually, with many CMS/forum packages, it is common to provide "unfudging" directives in the web server configuration for the site to make it easy on people who mistakenly put trailing slashes on the resource name. Typically, it is an Apache mod_rewrite rule which detects and corrects the error, and displays the correct page anyway, rather than doing the specification-correct action of returning a 404.

You are correct that it is non-standard (or "not consistent", but it is also very common.

That's the kind of woolly-headed, liberal thinking that leads to being eaten!

I think that really depends on whether the http://host:port/cap/key refers to a specific resource, or to something which is really a directory. They allow you to put a "path" beyond the cap which is returned to the script in a header, but it doesn't really "address" directories. If anything, it's just another parameter set which can use directory formatting.

In actuality, it doesn't really matter the exact formatting. As far as most webservers are concerned, you can really futz up a URL past the http://user:pass@host:port/ part, and as long as you provide the proper mechanism for it to translate it so it knows what to do with it beyond that, you can write it however you want. That's the beauty of things like mod_rewrite, especially with examples like MediaWiki, where the last identifier is the resource you are looking up, even though the actual resource loaded is something like "LoadPage.php".



With a lot of CMSs, it is more common than you'd think. Especially when passing around things like SIDs.

I'm not worried. I'm at the top of the universal food chain.

Bah, baryonic life is just froth on the great waves of dark matter that permeate the galaxies.

Practically, yeah, it almost certainly *is* handled as just a string sent to the script in the prim. My point is just that the behaviour it creates is consistent with a directory location as per HTTP spec, and as such not an error in how LL writes URLs, but a design choice in what the cap URL represents. (A design choice which avoids semantically overloading the base URL as both resource and directory and obeys the URL specification, at the cost of a "gotcha" for those who are used to a lenient parsing of URLs. Whether that is the optimal choice is another matter, but it *is* a valid choice, and not just a braindead error).

So true.

Yeah, given the way URLs have changed over the last decade or so, I am not so sure the original URI specification really should dictate whether a specific formatting beyond the host specification is syntactically correct or not. It pretty much has become application-specific.

Whether that is good or bad, I don't know, but that is what is happening.

the basic web protocol for addresses requires a trailing slash for folder level content, but can be optional enabled to redirect non trailing slashed versions to the proper location (if the server supports the feature)...

now LL might actually document that it is indeed a folder, and not some file name and save us all a lot of stupid questions down the road, or fiddling around to find out that it is indeed a folder reference..... but since when did LL document their code?

At this point I don't expect LL will change it. So it is what it is. My only hope was to explain why I wouldn't be forcing an ending slash onto people's URLs, which is because it breaks things where it's not expected and unwanted.

Of course these wouldn't be the SL forums if we didn't break out into a debate of semantics. Thanks everyone.

*waits for someone to say it's not semantics, and chuckles*

...or indeed write regression tests. The combination of which would explain why they have demonstrably lost control of the simulator implementation.

/esc

Well, the issue is that the URI spec was written at a time where the path/resource paradigm was the way it was physically implemented on webservers. Indeed, it was a path (from the website root directory) to that specific named resource that the webserver software loaded. Since that time, however, a lot has changed, and URIs past the method://user:pass@host:port part don't always map to an "actual" directory/resource structure. In fact, about the only requirements are that they continue to follow the basic syntactic semantics for the special characters ("/","@","#","%","?",":"), and encode the rest of the data. However, that is more for browser URI parsing than for webserver parsing, since the path/resource?param#fragment syntax is completely redefineable with things like mod_rewrite.

The same is true with the LSL http-in implementation. It is unlikely that the /cap/key actually refers to a directory/resource in the conventional sense, even as a stub.

Anyway, yeah, I don't think there is any need to do any kind of modification to stored URLs to compensate for whatever the user wants to store. That really should be handled in the client-side of the name resolver before it makes any request.

::just for Darien::
but it's not semantics, it's in the specification =)

(to which the proper response is: "all specifications are semantic"