Unfortunately sendsms isn't a script but a command defined
by the sendsms-url variable (which defaults to /cgi-bin/sendsms).
It is processed in smsbox.c and, on success, returns HTTP status
code 202 (Accepted) which, according to the spec, means the request
was accepted for processing but that processing has not been completed.
The spec also says the "entity returned with this response SHOULD include
an indication of the request's current status". Should the request fail,
for example, due to a white or blacklist restriction, the response code
may still be 202 and will contain something other than "Sent." Or if it
fails for another reason the response code may be 400 (Bad Request) or
500 (Internal Server Error), depending on the cause of the failure. Both
of those failure codes, according to the spec, "SHOULD include an entity
containing an explanation of the error situation".
In all cases, as near as I can tell from a quick perusal of the code,
sendsms and sendota command processing currently always returns
Content-Type: text/html, even though the response message typically
doesn't contain any HTML tags. At a minimum I'd think this should be
changed to text/plain if none of the code returning the response
content is doing any HTML formatting. Or perhaps sendsms_thread() in
smsbox.c could "look" at the contents of the answer variable returned
and try to guess at the content being returned and change the response
Content-type accordingly. For example, if it contains an html tag it
could assume text/html, if it contains a wml tag it could assume
text/vnd.wap.wml, etc. Not a perfect solution, but better.
Note to Ali Raza: If your mobile device or wap emulator can display
text/plain content, this might be the easiest solution for you. Just
change this line:
http_header_add(reply_hdrs, "Content-type", "text/html");
To this:
http_header_add(reply_hdrs, "Content-type", "text/plain");
In your copy of the smsbox.c: smsbox_thread() subroutine, then rebuild
it. Then at least you'd see the response.
Perhaps what would be useful here is a way for the sender to specify the format
of their expected response in some way. The Kannel administration interface
provides a status command which, by command extension convention, allows
the user to indicate the format in which they would like the response.
For example, using the command "status.txt" tells kannel to return the
response in plain text with Content-Type: text/plain, "status.html" tells it
to return the response in HTML form with Content-Type: text/html, "status.xml"
gets an XML response with Content-Type: text/xml and "status.wml" gets WML
with Content-Type: text/vnd.wap.wml. The code handling the status request
will also attempt to use the contents of the HTTP "Accept" header, if provided,
to choose the response Content-Type when no file extension is provided (i.e.
when the command is simply "status"). It fails over to text/plain if none of
the other Accept values are present. Thus, if the sender is able to control
the contents of the Accept HTTP header and they send an Accept header with
their GET method request for "status" that only includes "text/vnd.wap.wml",
then the response should be WML.
This convenience is not provided for the sendsms or sendota commands. It
could be provided either using a similar convention to the above, or by adding
an additional parameter to be parsed and handled by smsbox_req_sendsms() [and
smsbox_req_sendota()]. Or perhaps even to simply pay attention ot the
Content-Type
of the request and return a response Content-Type that matches the request
Content-Type. In fact, if the sendsms request method is a POST request
(actually,
it's assumed to be a POST if it includes a body) the code currently
interrogates
the Content-Type of the request in order to properly parse the body of the
request.
However, it still returns Content-Type: text/html as its response (see the
reply_hdrs
List in smsbox.c: sendsms_thread()) rather than attempting to format the
response
entity and Content-Type based upon the Content-Type of the request.
Should such a feature be desired one should take care to ensure that backward
compatibility is maintained. That way you don't break other people's code that
just expects "Sent." with response code 202 to indicate success. In particular,
smsc_http.c contains a kannel_parse_reply() subroutine that specifically looks
for "Sent." with response code 202 reply from a sendsms command it issues. To
change how the "Sent." response looks depending upon the Content-Type returned
could break this usage. In this case, however, changing octstr_case_compare()
to
octstr_case_search() might help, allowing there to be more than just "Sent." in
the response.
Another side note:
In order to be compliant with HTTP/1.1, all code handling any kannel commands
such
as status or sendsms should really be considering the contents of the Accept
header,
if present with the request, and return a 406 (Not Acceptable) return code if
the
Accept header is present and an acceptable response type cannot be determined.
Even the administration interface's handling of the status command, which does
look at the Accept header, fails over to text/plain even if text/plain is not
listed as being acceptable (or an acceptable wild card is provided such as */*).
Unless the spec requires that every requestor support text/plain responses (I'm
not sure if it does), this would not, technically, be HTTP/1.1 compliant as
near
as I can tell.
J.R.(Sydd)Souza
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of aliraza raza
Sent: Wednesday, June 21, 2006 6:16 PM
To: [email protected]
Subject: how to make change in sendsms scipt???
Hello Everyone!!
Most of you must have used http interface
to send sms messages. My URL for sending sms via http interface is
http://localhost:13013/cgi-bin/sendsms?username=tester&password=foobar&to=123&text=hy
When a message is sent a http page is opened with "Sent" written on it,
which confirms that the message is sent.
well i dont want that http page with sent written after the message is sent.
Becasue i want to call this url from a mobile device or wap emulator.A Http
page cant be shown on a mobile phone or emulator as only Wml (wireless
Markup Langauge) content can be shown on it. Due to that page i cant send
message from wap emulator.my smsbox receieves the Http request from where im
calling tht url from wap emulator but it dont receives the message.
plese tell me where i can find that sendsms script and how i can change that
script to generate a wml page rather than http page.
if this cant be done then can i make some change in sendsms script so that i
dont get that http page with Sent written on it after the message is sent.
replies are highly appreciated
Regards!!
Ali Raza
Student IT
Pakistan
_______________________________________________
users mailing list
[email protected]
http://www.kannel.org/mailman/listinfo/users