Root Cause Analysis (RCA) for the new AppNo SMS problem:
Observations Made
Our previous Script:
Constructs the URL using the requests library with the params argument.
Automatically handles URL encoding.
The SMS is not received, but the response indicates "SMS Accepted."
New Script (Mimicking curl):
Constructs the URL manually with explicit parameter encoding.
The SMS is received.
Key Difference:
URL encoding and parameter formatting.
Root Cause
The problem is in how the message (or other parameters) is encoded and sent to the SMS gateway.
URL Encoding in requests:
The params argument of requests.get() will automatically URL-encode parameters.
Some SMS gateways have particular encoding patterns that they are expecting, and the automatic
encoding might not be what the gateway is expecting.
For instance:
You have explicitly added %26 to your message (which represents &) in your message.
requests library might double encode or encode it wrongly while it is constructing the final URL
Manually Constructed URL (in curl-like script):
It explicitly encodes the parameters, ensuring they match the gateway's requirements.
This allows the gateway to parse the message and other parameters correctly.
Other Possible Gateway Expectations:
Parameter order: Some gateways are sensitive to the order of parameters, which is preserved
manually but not guaranteed with a dictionary in requests.
Formatting: The gateway might interpret slight differences in how spaces, special characters
(&, %, =), or line breaks are encoded.
Solution.
To repair the original script while keeping requests.get() for simplicity, you have to:
Manually Encode Parameters: Use urllib.parse to encode the parameters explicitly before passing
them to requests.
Construct URL Manually:
Build the URL string exactly as in the working curl example.
Changes Made.
Manual URL Encoding:
Utilized urllib.parse.urlencode to ensure all parameters are encoded uniformly.
Manual Construction of URL:
Built the full URL explicitly to emulate curl.
Printed Full URL:
Added a debug print to log the exact URL being sent for comparison with curl.
Final Thoughts.
The original script failed because the requests library's automatic encoding did not align with the
SMS gateway's expectations.
The updated script is using manual encoding and URL construction to match the behavior of the
working curl command.
---- ---- ---- --------
Make the script act more like a curl request. We do that by changing the function to send_sms to
look much more like curl's behavior. In a curl request, you would typically perform an HTTP
request and handle issues if any arise with retries or status codes. We'll add headers and data
handling, which you would do in a similar fashion with curl.
Key Modifications to Mimic curl Behavior:
HTTP Request Handling (curl-like behavior):
The requests.get() is used with the params dictionary, which closely mimics the query parameter-
based behavior of a curl request.
I’ve added error handling (response.raise_for_status()) similar to curl --fail, which will raise an
exception if the response status code is not successful (i.e., 4xx or 5xx).
Logging:
I have logged the full response as curl does with --verbose, so you can check the complete output
from the server.
SSL Certificate:
SSL verification is disabled similar to how curl --insecure disables verification by using
verify=False
Error Handling:
try-except is used similar to curl will use in error cases (like connection failures or HTTP errors).
The exception is logged exactly as a failed curl request
SMS Sending:
This approach will give us a behavior that is quite more like curl, even with error handling and even
logging responses.
Sends SMS using two different templates (English and Hindi) as it would have done initially.
