Best Way to send HTTP 200 OK code back to client
16 posts
• Page 2 of 2 • 1, 2
Re: Best Way to send HTTP 200 OK code back to client
Hi Tom,
The ⎕DM is set from an anticipated trapped error. The line in question is:
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
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
-
Brian|Dyalog - Posts: 116
- Joined: Thu Nov 26, 2009 4:02 pm
- Location: West Henrietta, NY
Re: Best Way to send HTTP 200 OK code back to client
Thanks!
Somehow I had missed ⎕DMX. There are so many goodies in the cookie jar it's hard to remember what's in there!
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: 23
- Joined: Sun Jul 23, 2017 11:37 am
Re: Best Way to send HTTP 200 OK code back to client
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.
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: 23
- Joined: Sun Jul 23, 2017 11:37 am
Re: Best Way to send HTTP 200 OK code back to client
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.
-
StefanoLanzavecchia - Posts: 109
- Joined: Fri Oct 03, 2008 9:37 am
Re: Best Way to send HTTP 200 OK code back to client
⎕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.
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.
-
Adam|Dyalog - Posts: 135
- Joined: Thu Jun 25, 2015 1:13 pm
Re: Best Way to send HTTP 200 OK code back to client
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!
-
StefanoLanzavecchia - Posts: 109
- Joined: Fri Oct 03, 2008 9:37 am
16 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group