Multiple Issues/Feedback

[quinnj]

Hey @tanmaykm, @viralshah

I'm a little slammed at the moment, but wanted to share some feedback and thoughts on taking this for a test drive for the last week:

• For some reason, the logging functionality didn't work for me; I just ended up with empty .log files. I ended up putting println()s everywhere there were Logging actions and that worked really well to spin up two terminals and run the server in one and the invoker in another
• It'd be nice to be able to Ctrl+C the Invoker (doing it to the server worked just fine). Just more convenient to Ctrl+C than have to kill the process
• I had an issuer where I wasn't able to return non-JSON, the diff below fixed it for me

@@ -61,8 +64,12 @@ function get_resp(api::Nullable{APISpec}, status::Symbol, resp::Any=nothing)
     stcode = st[2]
     stresp = ((stcode != 0) && (resp === nothing)) ? "$(st[3]) : $(st[2])" : resp

-    if !isnull(api) && get(api).resp_json
-        return @compat Dict{String, Any}("code" => stcode, "data" => stresp)
+    if !isnull(api)
+        if get(api).resp_json
+            return JSON.json(stresp)
+        else
+            return stresp
+        end
     else
         return stresp

• I had to change all the info calls to Logging.info because of the recent change to Base that kills both names when they clash
• Doing some long-running connections, I often ran into the error below; not sure if there's a nicer way to handle this or how "bad" this is to encounter

ERROR (unhandled task failure): ArgumentError: stream is closed or unusable
 in check_open at stream.jl:301

A few questions:

• How do request headers come through? Is there a way to access them from a function call? I ask because I'm interested in doing some basic authentication through header values (I guess I could do it through query parameters instead...)
• How can you tell what HTTP method was used in invoking a call? I was only trying GET, but may want to shift to POST

Again, sorry for the mess here and not doing proper PRs, but wanted to share some feedback. Hopefully I'll be able to contribute more soon.

[tanmaykm]

Thanks for the feedback @quinnj

Currently the Julia API methods are oblivious of the HTTP protocol. The idea was to have separate filters that map HTTP headers to method parameters, and keep the API methods independent of the protocol. Filters would also perform authentication, request logging and such tasks. Does this sound right?

Will check the stream is closed error. Was there any more of the exception stack that pointed to the source line?

[quinnj]

The stream is closed error was in the APIInvoker and occurred when my client's stream closed prematurely before the API could generate the response.

One other point of feedback:

• Maybe this was user error, but as is, I had to manually remove a few JSON.json/JSON.parse calls because they die on "invalid UTF8" data when I pass gzipped data as a string. If I pass it as a Vector{UInt8}, should that work? I realize I didn't try that, but on the other hand, it didn't seem to seriously break anything by just remove the JSON calls. Could they be removed for some efficiency?

[tanmaykm]

@quinnj I had only meant to return HTML / JSON responses. But I think binary responses are a necessity for many applications. I think a little tweaking would enable that. Could you point out where you made the changes?

I shall push a few changes tomorrow, to fix some of the points discussed here.

[tanmaykm]

@quinnj please try binary responses with the latest changes. You should be able to pass gzipped data with this.
Also added some sample code to refer.

[aviks]

Much of this has been addressed, and others are probably state at this point. closing.