I am using .Q.hp to send a message to symphony bot .
.Q.hp[hsym`$"host";"";"chatRoomName;someHTMLTable"]
If I run the above in the browser I usually get something back like "duplicate message" or "room does not exist", but .Q.hp only returns an empty string ""
How can I see if a message is being received from the alert bot?
Is .Q.hp asynchronous and is kdb not waiting for anything back?
You can make a custom .Q.hp2 that returns a response which is a two-item list (of strings) - by default .Q.hp only returns the second item in that list. The first item in the response might give you the info you're looking for.
q).Q.hp2:{.Q.hmb[x;`POST;(y;z)]}
q)res:.Q.hp2["http://google.com";.h.ty`json]"my question"
q)res 0
"HTTP/1.1 405 Method Not Allowed\r\nallow: GET, HEAD\r\ndate: Wed, 15 Dec 2021 02:09:14 GMT\r\nco..
q)res 1
"<!DOCTYPE html>\n<html lang=en>\n <meta charset=utf-8>\n <meta name=viewport content=\"initial..
Tested with v4.0 build 2021.07.12
Related
I'm trying to send a SMS using AT commands and after typing the cellphone number it show the CMS: ERROR 302.
What I'm doing:
AT
OK
AT+CMGF=1
OK
AT+CMGS="<3 digit local area code><7 digit cellphone number>"<Enter>
+CMS: ERROR 302
I've found this post: AT+CMGS returns ERROR but couldn't find a solution. Am I typing something wrong? I've changed SMS-encoding to GMS as the post describes.
Try this:
AT
AT+CMGF=1
AT+CSCA="sms tel. service",145
AT+CMGS="tel. number"
text message here
^Z
Some modems need set CSCA (SMS Service Center Address) always.
And look here for a examples and descriptions.
I found out that sending exactly the same AT commands by hand worked, but sending them from a controller did not (with waiting for the correct answers). Getting the 302 error. But then doing all commands a lot slower with waits of 2 secs in between it suddenly started to work. Apparantly the SIM900 needs more time after it answers, or something.
I have 2 resources User and Album. A user has a list of albums. To get albums there are 2 REST API.
user/{userId}/albums/{albumId} gets album by albumId. If not found returns 404
user/{userId}/albums gets all albums by userId. In this case, if a user has no albums, what should be the status code 204 or 404?
Is the absence of any album really seen as an error? Assuming the albums are returned as a JSON array, the common response to such a situation would be a HTTP 200 with an empty array as the body.
Returning 404 signals that the resource doesn't exist, kind of saying that it isn't even possible to ask for the list of albums for this particular user. But in fact, it's possible to successfully return the list of albums, it's just that the list is empty. It doesn't seem at all exceptional to me. This is completely in contrast to retrieval of one specific album using an ID that doesn't exist (using your other endpoint); in such a situation a 404 is correct.
While a 204 seems better than a 404, because it at least tells the client that the request was successful but had no content, its intention is not really to be used to signal a "successful absence". Rather, it signals that the resource DOES exist but for some reason the server chose not to include the resource in the response body - for example the purpose of the request could have been to simply pass back some headers to the client.
A 204 can also be used as a response to a POST request where some action was carried out by the server without necessarily creating any new resource (which would have implied a 201 CREATED), or where it's for some other reason not relevant to return any resource.
I think it's clear that what you need is a
GET /user/xxx/albums
HTTP/1.1 200 OK
[]
Here is what the RFC2616 that defines the HTTP protocol says about Status-codes:
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are
5 values for the first digit:
- 1xx: Informational - Request received, continuing process
- 2xx: Success - The action was successfully received,
understood, and accepted
- 3xx: Redirection - Further action must be taken in order to
complete the request
- 4xx: Client Error - The request contains bad syntax or cannot
be fulfilled
- 5xx: Server Error - The server failed to fulfill an apparently
valid request
In your case, the request was successful, but there are no albums to show, so you definitely should use a status from the 2xx category.
Here is what the RFC says about the 204 status:
10.2.5 204 No Content
The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.
If the client is a user agent, it SHOULD NOT change its document
view from that which caused the request to be sent. This response
is primarily intended to allow input for actions to take place
without causing a change to the user agent's active document view,
although any new or updated metainformation SHOULD be applied to
the document currently in the user agent's active view.
The 204 response MUST NOT include a message-body, and thus is
always terminated by the first empty line after the header fields.
The RFC states that the 204 is primarily intended to allow inputs, so you shouldn't use this one. I would use the 200 in this case.
Error Code 404
The web site hosting server will typically generate a "404 Not Found" web page when a user attempts to follow a broken or dead link.
Return Code 204
The server has fulfilled the request but does not need to return an entity-body.
Conclusion
You obviously need to return a 204 status code. If you use the 404 one, the user may be disturbed. More, you use 404 when the targeted album doesn't exist. Using 404 for both 1 and 2 is illogical.
When you ask for a specific resource, say a user, and the user doesn't exist, then you should return 404. For example, you have an API to retrieve a user using the following URL:
https://yourdomain.com/api/users/:userid
and a request is made to retrieve user 1234, that doesn't exist, then you should return 404. In this case, the client requested a resource that doesn't exist.
https://yourdomain.com/api/users/1234
404
Now suppose you have an api that returns all users in the system using the following url:
https://yourdomain.com/api/users
If there are no users in the system, then, in this case, you should return 204.
Let me give my 2 cents on this. I hope you already know the difference between 404 vs 204.
The scenario i would prefer to use each status code are :
404 Status Code
404 means that the Resource not found or doesn't exist or URL is invalid
For example
GET : https://api.myapp.io/product/product_id_123
GET : https://api.myapp.io/image/nokia.jpg
If the single product / resource item doesn't exist in database or in resource folder, that means the resource of this URL is invalid so we have to throw 404 and Search Engines like Google & bing will not going to cache the result and will not retry again the next day for fresh content.
204 Status Code
204 means that the URL is valid and Server has successfully did the execution but it has no data to return.
For example
GET : https://api.myapp.io/product/search?keyword=nokia
If there is no data matched (single or multiple) for the keyword in database to return back the results, then throw 204 because there is no data to return but the URL is still valid and Search Engines like Google & bing will retry again the next day for fresh content because for them it is not invalid url and when you retry the next day there might be some data which matches the query.
I agree with the responses, but I think is 204 or 200, it depends of your response when the album list is empty.
If you will return a empty array, the return it with 200 code, if you prefer to don't return anything, then the right one will be 204. (I prefer a 200 with empty list)
Only use 404 with a resource doesn't existis, if it is a empty list the choose 204 or 200.
Good hacking man!
I am trying to build a lightstreamer client for Matlab. There do exist a couple of libraries for platforms like JAVA, Python, .Net etc. But unfortunately not Matlab.
However, it turns out that most of these client implementations use the very same text-mode protocol for lightstreamer which is pretty basic HTTP requesting.
I figured out how to establish/close a lightstreamer session. I get the sessionId and I can use this id to subscribe to the data I want to stream. But although I do get a valid response for the subscription call, there is no data pushed.
I use the urlead2 function and the response seems fine:
[output,extras] = urlread2([lightstream_url,'/lightstreamer/control.txt'],'POST',body,headers);
allHeaders =
Response: {'HTTP/1.1 200 OK'}
Server: {'Lightstreamer'}
Content_Type: {'text/plain; charset=iso-8859-1'}
Cache_Control: {'no-store' 'no-cache'}
Pragma: {'no-cache'}
Expires: {'Thu, 1 Jan 1970 00:00:00 GMT'}
Date: {'Wed, 8 Apr 2015 11:15:02 GMT'}
Content_Length: {'4'}
status =
value: 200
msg: 'OK'
isGood =
1
output =
OK
It is correct that the response body contains "OK ", this is documented (documentation, page 20ff.), but there is supposed to be the stream data itself as well, isn't it?
So how do I get the actual data?
Somewhere in your code you should have a create_session.txt/bind_session.txt request, otherwise you should not have a valid session id that is required to obtain an OK answer from a control.txt request (e.g. the following generates the SYNC ERROR, that means that the server does not recognize the specified session: http://push.lightstreamer.com/lightstreamer/control.txt?LS_op=add&LS_session=invalid )
The data stream is not received on the control.txt response, that OK response simply means "OK I have added the subscription to your session".
The data stream is received on the create_session.txt/bind_session.txt response. Sections 4.1 and 4.2 + section 4.5 on the document you linked should explain how the data is received
I've found that opening a polling connection by setting LS_polling=true works fine without needing a listner. urlread2 hangs if you leave LS_polling as the default of false.
Create the session with /lightstreamer/create_session.txt
Request a subscription with /lightstreamer/control.txt
Repeatedly poll the connection to get the data with
/lightstreamer/bind_session.txt
The return from urlread2 will look something like this:
d =
OK
SessionId:S9b09da8ebd6b835aT5316913
ControlAddress:apd119a.marketdatasystems.com
KeepaliveMillis:1000
MaxBandwidth:0.0
RequestLimit:50000
1,1|10162.00|0.00|0.00
2,2|10686.8|TRADEABLE|0.5524861
2,13|1202.6|CLOSED|0.5714285
2,14|5900.51|CLOSED|0.5714285
...
LOOP 1000
i have this as my dgrid constructor ,
var MyQuickGrid = declare([onDemandGrid,Keyboard,Selection,ColumnHider,ColumnResizer,ColumnReorder]);
and the partial config_opts are
var config_opts = {
loadingMessage: " Loading data...",
noDataMessage: "No results found."
}
.
.
.
lang.mixin(grid_opts,config_opts);
window.grid = new MyQuickGrid(grid_opts,'node_of_intrest');
however when i request data from the server using a JsonRESTStore, and the returned json data is empty i.e "[]" the grid does not display the "noDataMessage", i initially thought this was because of the headers i was returning, since i was returning 200 OK even for empty results set, i changed this to 204 No Content but still nothing seems to be working. I would appreciate a work around, or even a way to know if the grid failed to get results cuz this native feature for some reasons seem to be too smart for me for now.
Mentioned by nbjoerg on IRC
make sure your JsonRest server is setting the proper Content-Range headers in its query responses (e.g. in this case it should be "items 0-0/0").
For more info on how Dojo expects JsonRest endpoints to behave, see http://dojotoolkit.org/reference-guide/1.9/quickstart/rest.html
Here's an example of the headers returned by a JsonRest service for which noDataMessage displays fine:
Connection:Keep-Alive
Content-Length:2
Content-Range:items 0-0/0
Content-Type:application/json
Date:Thu, 19 Sep 2013 12:56:19 GMT
Keep-Alive:timeout=5, max=92
Server:Apache/2.2.12 (Win32) DAV/2 mod_ssl/2.2.12 OpenSSL/0.9.8k mod_autoindex_color PHP/5.3.0
X-Powered-By:PHP/5.3.0
And a screenshot, for good measure:
What is the appropriate way of giving an estimate for request completion when the server returns a 202 - Accepted status code for asynchronous requests?
From the HTTP spec (italics added by me):
202 Accepted
The request has been accepted for processing, but the processing has not been completed. [...]
The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
Here are some of thoughts:
I have glanced at the max-age directive, but using it would be abusing Cache-Control?
Return the expected wait time in the response body?
Add an application specific X- response header, but the X-headers was deprecated in RFC 6648?
Add a (non X-) specific response header? If so, how should it be named? The SO question Custom HTTP headers : naming conventions gave some ideas, but after the deprecation it only answers how HTTP headers are formatted, not how they should be named.
Other suggestions?
Definitely do not abuse existing HTTP headers for this. Since it's your own server, you get to define what the response looks like. You can (and should) pick whatever response works best for the intended recipient of this information and return the actual information in the response body.
For example, if you are only interested in displaying a human-readable message then you could return text/plain saying "Your request is likely to be processed in the next 30 minutes.".
At the other end of the spectrum, you might want to go all the REST way and return application/json, perhaps formatted like this (I totally made this up on the spot):
{
"status": "pending",
"completion": {
"estimate": "Thu Sep 08 2011 12:00:00 GMT-0400",
"rejected-after": "Fri Sep 09 2011 12:00:00 GMT-0400",
},
"tracking": {
"url": "http://server/status?id=myUniqueId"
}
}
You can use the Location header to specify the URL of the status monitor. Things like current status and estimate can either go in custom headers (which noone but your own software would use), or in the response body (which a web browser would display to a user, at least).
Although not explicitly mentioned specifically for the 202 - Accepted response code, the Retry-After header seems to be a suitable option. From the documentation:
The Retry-After response-header field can be used [...] to indicate how long the service is expected to be unavailable to the requesting client.