Best Way to send HTTP 200 OK code back to client

MiServer is Dyalog's APL-based web development framework

Re: Best Way to send HTTP 200 OK code back to client

Postby Brian|Dyalog on Tue Mar 12, 2019 2:21 pm

Hi Tom,

The ⎕DM is set from an anticipated trapped error. The line in question is:
      secure←{6::⍵ ⋄ ⍵∨0<⍴,certs}(lc(p-2)↑url)≡'https:'

which attempts to discern if the request should use HTTPS - either because the URI begins with 'https:' or you've passed a certificate as an argument in certs. If certs doesn't exist, then we just use the URI. The 6::⍵ is the trap for the VALUE ERROR.

From the brief description of your application, I think there may be an issue with HttpCommand initialization if you send requests on separate threads before the first request has initialized. I'll look into this further.

I hope this helps!
/Brian
User avatar
Brian|Dyalog
 
Posts: 87
Joined: Thu Nov 26, 2009 4:02 pm
Location: West Henrietta, NY

Re: Best Way to send HTTP 200 OK code back to client

Postby tomgarwin on Tue Mar 12, 2019 4:08 pm

Thanks!

Somehow I had missed ⎕DMX. There are so many goodies in the cookie jar it's hard to remember what's in there!
tomgarwin
 
Posts: 18
Joined: Sun Jul 23, 2017 11:37 am

Re: Best Way to send HTTP 200 OK code back to client

Postby tomgarwin on Tue Mar 12, 2019 4:46 pm

Thanks very much, Brian.. I had replied to Andy's post before seeing yours.

I hadn't known how to read the 6::⍵ idiom... I really do need to take some time out and learn modern APL!

For now I've put :Hold/:EndHold around the use of HttpCommand. But it would be good to know whether it is completely safe for multiple threads or if it runs fine in multiple threads once initialized. Luckily my application is pretty lazy/forgiving regarding timing.
tomgarwin
 
Posts: 18
Joined: Sun Jul 23, 2017 11:37 am

Re: Best Way to send HTTP 200 OK code back to client

Postby StefanoLanzavecchia on Wed Mar 13, 2019 2:56 pm

AndyS|Dyalog wrote:I also recommend, when developing code, to get into the habit of running d←⎕dmx as soon as the error is signalled and then look at what's in d


This comment gives the chance something I'd been meaning to ask for a long time. ⎕DMX looks and (beautifully) smells like a namespace. So, an expression like d←⎕dmx should only be able to make d a ref to the target namespace. But something magical seems to happen if another error is signalled: when that happens, d keeps pointing to the old ⎕dmx. My question are: is this something we can really on? In other words, could I build an array of []DMX by collecting them when I see fit and they would all be separate instances? Also, when are the properties filled in? Some languages delay the computation of the actual properties of an exception until they are looked at. Which, in the case of properties like OSError could be "too late" if in the meantime I had managed to call another Win 32 API which overwrote GetLastError. Does Dyalog fill all the properties immediately, or at least keeps attached to that instance all it needs to compute the properties or should I look at those properties as soon as possible to fix them?

Cheers.
User avatar
StefanoLanzavecchia
 
Posts: 64
Joined: Fri Oct 03, 2008 9:37 am

Re: Best Way to send HTTP 200 OK code back to client

Postby Adam|Dyalog on Wed Mar 13, 2019 3:14 pm

⎕DMX is actually a niladic system function, returning a ref to an instance of an internal class (wrapped up as an APL namespace) which contains the latest error information for the current thread. While some properties may be "filled in" late, the object does contain everything it needs. There is no rush in querying values.

Once a new error happens, the old object will only persist if you're holding a ref to it, because ⎕DMX will now return a ref to the newly generated object. So if you concatenate the result of ⎕DMX to your error collection, then yes, you can rely on this result being stable.
User avatar
Adam|Dyalog
 
Posts: 62
Joined: Thu Jun 25, 2015 1:13 pm

Re: Best Way to send HTTP 200 OK code back to client

Postby StefanoLanzavecchia on Wed Mar 13, 2019 3:16 pm

Adam|Dyalog wrote:⎕DMX is actually a niladic system function, returning a ref to an instance of an internal class (wrapped up as an APL namespace) which contains the latest error information for the current thread. While some properties may be "filled in" late, the object does contain everything it needs. There is no rush in querying values.

Once a new error happens, the old object will only persist if you're holding a ref to it, because ⎕DMX will now return a ref to the newly generated object. So if you concatenate the result of ⎕DMX to your error collection, then yes, you can rely on this result being stable.


All clear. Thank you. And... Cool!
User avatar
StefanoLanzavecchia
 
Posts: 64
Joined: Fri Oct 03, 2008 9:37 am

Previous

Return to MiServer

Who is online

Users browsing this forum: No registered users and 1 guest