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: users@kannel.org
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
users@kannel.org
http://www.kannel.org/mailman/listinfo/users

Reply via email to