AltME: Web

Messages

Maxim
Does anyone know if there is any problem with using a ":" within a http URL, for the *target* part of the path.  
as such, the URL doesn't have any relation to physical disk paths.
ex:
http://mydomain.com/stuff/group:resource
I have the above working on a server, and browsers I've tested do not seem to have any problem with the URL, but I'm wondering more at large, if there are issues with it, in general.
It will be used  from within applications (java, .net, php & rebol) much more than from users manually using it within a browser bar.
rebol doesn't url encode the character, so it seems like its a valid character, but I don't want to assume, if some standard toolset doesn't like the color in the target.
color == colon  :-)
Sunanda
rfc1738 says ":" is a reserved character for possible special meaning in some schemes. It does not seem to have any special  meaning in the schemes mentioned in that URL.
But its reserved status means that it does not have to be encoded in any URL.
That's the theory, anyway. Practice may show otherwise.
https://tools.ietf.org/html/rfc1738
Gregg
The iMatix guys use it for both zeromq stuff and wikidot.
Maxim
true, good references, so I won't panick about it then  :-)

MaxV
to-url is your friend
Oldes
Are you sure Max?
>> x: to-url "@@@"
== @@@
Maxim
all the string-based datatype convertion funcs are flawed in some un-expected ways.   for example, you can to-word a lot of strings which aren't valid words.  
this is why I asked.  Although R2 doesn't complain, it doesn't mean tis valid or expected.
R3 did some housecleaning in type convertion consistency, but it has some flaws left (and I expect we will keep finding new ones).

MaxV

Janko
Hi, I am looking into OAuth. I see (and thank you a lot for this!) that Chriss Ross Gill created OAuth client part in the twitter library: http://reb4.me/r/twitter.html , I am reading into it, but does he or anyone else know how much additional work would be needed to do the rebol OAuth server part ?

Chris
I don't think it'd be that difficult - most of the difficulty in the client was making sure all the hashing was correct, the rest is just storage and logic.
Chris
For the most part, authorisation is based the parameters of a request hashed with a private key.  The trickiest part I'd imagine is the initial authentication - providing a safe method for the end user to allow the client to obtain and use the key.
End user downloads X's app/uses your
Chris
End user X downloads Y's app/uses Y's web site; X tries to access a function that uses your site; Y requests a temp key from you; Y directs X to your site with temp key, X says Y is OK, you give X a PIN; X goes back to Y, enters PIN; Y requests the permanent key from you.  Y can now do anything on your site on behalf of X.
Nothing to it : )

Last message posted 35 weeks ago.