http GET request
142 views
Skip to first unread message
anon
Sep 10, 2013, 3:46:04 PM9/10/13
to kona...@googlegroups.com
I believe
(`"www.google.com";`http) 4: "GET /"
or
(`"http://ichart.yahoo.com";`http) 4: "GET /table.csv?s=GOOG"
should work with K3, no?
I'm getting a type error.
thanks,
(`"www.google.com";`http) 4: "GET /"
or
(`"http://ichart.yahoo.com";`http) 4: "GET /table.csv?s=GOOG"
should work with K3, no?
I'm getting a type error.
thanks,
Tom Szczesny
Sep 13, 2013, 3:03:20 PM9/13/13
to kona...@googlegroups.com
On k2.8, I get the following results:
K 2.8 2000-10-10 Copyright (C) 1993-2000 Kx Systems
Evaluation. Not for commercial use.
\ for help. \\ to exit.
(`"http://ichart.yahoo.com";`http) 4: "GET /table.csv?s=GOOG"
value error
(`"http://ichart.yahoo.com";`http) 4: "GET /table.csv?s=GOOG"
^
Tom Szczesny
Sep 13, 2013, 3:08:16 PM9/13/13
to kona...@googlegroups.com
I get the exact same results using k3.2 (as I did using k2.8).
Tom Szczesny
Sep 13, 2013, 3:11:49 PM9/13/13
to kona...@googlegroups.com
Using kona, I get "type error" for each command:
K Console - Enter \ for help
(`"www.google.com";`http) 4: "GET /"
type error
(`"http://ichart.yahoo.com";`http) 4: "GET /table.csv?s=GOOG"
type error
Tom Szczesny
Sep 13, 2013, 3:19:30 PM9/13/13
to kona...@googlegroups.com
If I use my browser, and attempt to go to
I get the error message:
"Sorry, the page you requested was not found".
Clearly, kona is not producing the same results as k2.8 or k3.2,
but I would like to get a working example in either k2.8 or k3.2
before attempting to "fix" kona.
Kevin Lawler
Sep 14, 2013, 12:20:42 AM9/14/13
to kona...@googlegroups.com
I don't remember this from any version of K I used. The syntax seems pretty odd to me, too: "`http" does not specify a port, and then the http plaintext is dictated instead of somehow handled. It also looks like it does socket-oblivious communication, which has its pros and cons however you implement it. As far as I know socket-oblivious communication has not been an allowance in K.
Implementing a synchronous and asynchronous socket-aware plaintext sends, to correspond with the K-IPC sends 3: and 4:, would be an easy and nice addition to Kona. You would get telnet and other plaintext socket services out of this too, not just HTTP. The K syntax would take some thinking. The C syntax would be hard to mess up. If anyone wants to add this they're welcome to try.The K syntax should be submitted to the list for review first.
Kevin
Kevin Lawler
Sep 14, 2013, 12:39:37 AM9/14/13
to kona...@googlegroups.com
Worth noting:
a:`4:"curl -L google.com"
1#a
,"<!doctype html><html itemscope=\"\"
itemtype=\"http://schema.org/WebPage\"><head><meta content=\"Search
the world's information, including webpages, images, videos and more.
Google has many special features to help you find exactly what you're
looking for.\" name=\"description\"><meta content=\"noodp\"
name=\"robots\"><meta itemprop=\"image\"
content=\"/images/google_favicon_128.png\"><title>Google</title><script>(function(){"
a:`4:"curl -L google.com"
1#a
,"<!doctype html><html itemscope=\"\"
itemtype=\"http://schema.org/WebPage\"><head><meta content=\"Search
the world's information, including webpages, images, videos and more.
Google has many special features to help you find exactly what you're
looking for.\" name=\"description\"><meta content=\"noodp\"
name=\"robots\"><meta itemprop=\"image\"
content=\"/images/google_favicon_128.png\"><title>Google</title><script>(function(){"
Bakul Shah
Sep 14, 2013, 2:28:13 AM9/14/13
to kona...@googlegroups.com
Try
--
You received this message because you are subscribed to the Google Groups "Kona Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kona-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Tom Szczesny
Sep 14, 2013, 11:53:39 AM9/14/13
to kona...@googlegroups.com
Very nice !
Message has been deleted
Kevin Lawler
Sep 14, 2013, 4:02:17 PM9/14/13
to kona...@googlegroups.com
I looked into this. Apparently it does respect ports, doesn't require
socket/handle management, and doesn't handle HTTP redirects/etc. The
token "`http" is a misleading choice. Ignoring the absence of handle
management, it works a lot like the socket extensions described
earlier the thread. This was a convenience method added via operator
overloading.
I think the idea of adding socketless sends via overloading is
interesting. You could do
(`"localhost:1234";`ipc) 4: "a:1"
for a socketless IPC send.
Then perhaps you could do
(h;`http) 4: "GET /"
for a stateful send, where h is an integer atom representing an "http"
handle. Possibly you could open this handle using
3: (`"hostname";80;`http)
Without looking I can't tell whether you can use the same handles for
either IPC or HTTP. There is an IPC handshake so I think not.
The token `text or similar is perhaps a better choice than `http.
I think HTTP redirects and the like should not be added. At that point
you are reimplementing cURL.
Kevin
socket/handle management, and doesn't handle HTTP redirects/etc. The
token "`http" is a misleading choice. Ignoring the absence of handle
management, it works a lot like the socket extensions described
earlier the thread. This was a convenience method added via operator
overloading.
I think the idea of adding socketless sends via overloading is
interesting. You could do
(`"localhost:1234";`ipc) 4: "a:1"
for a socketless IPC send.
Then perhaps you could do
(h;`http) 4: "GET /"
for a stateful send, where h is an integer atom representing an "http"
handle. Possibly you could open this handle using
3: (`"hostname";80;`http)
Without looking I can't tell whether you can use the same handles for
either IPC or HTTP. There is an IPC handshake so I think not.
The token `text or similar is perhaps a better choice than `http.
I think HTTP redirects and the like should not be added. At that point
you are reimplementing cURL.
Kevin
Reply all
Reply to author
Forward
0 new messages