Boost Asio receive unknown Number? - c++

I wrote a Http/Rest Client.
The Main Problem is that i recieve some unkown digits within the requested data.
I really don´t know where they come from..
e0b
<html>
<head>
[...]
</body>
</html>
0
You see the e0b and the 0 at the end.
In big xml files for example i got something like this:
<sometag id="somei
2000
d"><child>
...
</child></some
2000
tag>
It is irreproducible by me.
My Code:
// read the response status code
boost::asio::streambuf httpStreamBufferResponse;
boost::asio::read_until(httpSocket, httpStreamBufferResponse, "\r\n");
// check status code and validate
istream httpResponseIStream(&httpStreamBufferResponse);
// temp var for version
string sHttpVersion;
httpResponseIStream >> sHttpVersion;
// temp var for status code
unsigned int uiStatusCode;
httpResponseIStream >> uiStatusCode;
// fetch status message and switch it
string sStatusMessage;
getline(httpResponseIStream, sStatusMessage);
if(!httpResponseIStream || sHttpVersion.substr(0, 5) != "HTTP/"){
new Note(eNotesType(ERROR), "Request Interrupt", "Invalid Request Response");
Log::write("ERROR: Request Interrupt: Invalid Request Response");
}
// != 200 even means that something is not OK
if(uiStatusCode != 200){
this -> sHttpStatusCode = uiStatusCode;
new Note(eNotesType(WARNING), "Request Response "
+ boost::lexical_cast<string>(uiStatusCode), httpErrorToString.at(uiStatusCode));
Log::write("WARNING: Request Response "
+ boost::lexical_cast<string>(uiStatusCode) + ": " + httpErrorToString.at(uiStatusCode));
}
// Read the response headers, which are terminated by a blank line.
boost::asio::read_until(httpSocket, httpStreamBufferResponse, "\r\n\r\n");
// Process the response header
stringstream responseSStream;
string responseSHeader;
while (getline( httpResponseIStream, responseSHeader ) && responseSHeader != "\r" ) {
responseSStream << responseSHeader;
}
// store header in member variable
this -> sHttpResponseHeader = sHttpVersion + " " + boost::lexical_cast<string>(uiStatusCode) + " "
+ httpErrorToString.at(uiStatusCode) + "\n" + responseSStream.str();
// read until EOF and writing data to output as we go.
ostringstream responseOSStream;
while(boost::asio::read(httpSocket, httpStreamBufferResponse, boost::asio::transfer_at_least(1), error)){
responseOSStream << &httpStreamBufferResponse;
}
// store content in member variable
this -> sHttpResponseContent = responseOSStream.str();
// if there is no EOF
if(error != boost::asio::error::eof){
new Note(eNotesType(ERROR), "Request Interrupt", "Invalid Response End");
Log::write("ERROR: Request Interrupt: Invalid Response End");
}
// catch not known exceptions properly
} catch (exception& e){
string exceptionMessage = e.what();
new Note(eNotesType(ERROR), "Exception", exceptionMessage);
Log::write("ERROR: Exception: " + exceptionMessage);
}
// log http standby
Log::write("http status: standby");
It would be a great pleasure if anybody got ANY idea where this come from..?!
My nerves are on edge..

Your code is claiming HTTP/1.1 compliance and doesn't actually comply with HTTP/1.1's requirements. Either don't claim HTTP/1.1 compliance or make sure your code does everything the standard says a client must do.
All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding, and MUST ignore chunk-extension extensions they do not understand. -- HTTP/1.1 specification, section 3.6.1

Related

curlpp response is doubled

I'm just new to curlpp but I can't see what's wrong here with my code, so I hope someone can help me out.
I'm using curlpp in C++ to make Facebook Graph queries. That means the Facebook server will return Json data as result.
My code looks as follows:
#include <curlpp/cURLpp.hpp>
#include <curlpp/Easy.hpp>
#include <curlpp/Options.hpp>
#include <curlpp/Exception.hpp>
...
curlpp::Easy myRequest;
bool error = false;
QString result = "";
try {
// Setting the URL to the Facebook server with the query
curlpp::options::Url myUrl(request->getURL().toStdString());
// Creating stream for the result
std::ostringstream os;
curlpp::options::WriteStream ws(&os);
// setting my opts: url and output stream
myRequest.setOpt(myUrl);
myRequest.setOpt(ws);
// perform the request
myRequest.perform();
// stream the result into my stream
os << myRequest;
result = QString::fromStdString(os.str());
} catch (curlpp::RuntimeError &e) {
error = true;
qWarning() << "Error in HttpRequest execution:" << e.what();
} catch (curlpp::LogicError &e) {
error = true;
qWarning() << "Error in HttpRequest execution:" << e.what();
} catch (...) {
error = true;
qWarning() << "Unknown error in HttpRequest execution.";
}
My problem now is that the resulting stream (and thus my result QString) do contain the Json object sent by the Facebook Graph server, but twice.
That means, directly two times the same object, one after the other. And that makes it invalid Json.
But that can not be what the server delivers. And it's not what I get when I do check it with the openssl command line tool and make a HTTP Get request on my own.
What's wrong with my code?
Best, Michael

Using c++ to send smtp mail

I was wondering if you could help me understand what is going wrong here. I am trying to write a little client that engages in SMTP dialogue on port 25.
If you recall SMTP, there's a few things you need to send, and then you write the email after the DATA message, ending with a period on it's own line to send the email.
There is something problematic in the way the program handles this. It handles the dialogue fine until after the DATA message. It will recognize the period only if I type it first. After any subsequent line, any code execution seems to be lost. The if statement fails to recognize if a period has been entered. Thank you again. Attached is the relevant code..
void readstuff(int sock, char* buf) {
int r = read (sock, buf, BUFSIZE -1);
buf[r] = NULL;
cout << buf << endl;
}
void doit(int sock, string arg, char* buf) {
int r = write(sock, arg.c_str(), arg.length());
readstuff(sock, buf);
}
int main(int argc, char *argv[]) {
char buf[BUFSIZE];
// Make a socket
int sock = MakeSocket(argv[1], argv[2]);
cout << "socket is " << sock << endl;
assert(sock != -1);
// Begin dialogue
doit(sock, "HELO " + org.substr(org.find("#") + 1) + "\r\n", buf);
doit(sock, "MAIL FROM: <" + org + "> \r\n", buf);
doit(sock, "RCPT TO: <" + dest + "> \r\n", buf);
doit(sock, "DATA \r\n", buf);
readstuff(sock, buf); //should say "go ahead"
//User writes email here
while (true) {
string line = "";
getline(cin, line);
doit(sock, line + "\r\n", buf);
if (line == ".") {
readstuff(sock, buf); //should say "email cleared to send"
return 0;
}
}
}
Please read the SMTP specification, RFC 5321, particularly sections 4.1.1.4 DATA and 4.5.2 Transparency:
4.1.1.4. DATA (DATA)
The receiver normally sends a 354 response to DATA, and then treats
the lines (strings ending in <CRLF> sequences, as described in
Section 2.3.7) following the command as mail data from the sender.
This command causes the mail data to be appended to the mail data
buffer. The mail data may contain any of the 128 ASCII character
codes, although experience has indicated that use of control
characters other than SP, HT, CR, and LF may cause problems and
SHOULD be avoided when possible.
The mail data are terminated by a line containing only a period, that
is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is
actually the terminator of the previous line (see Section 4.5.2).
This is the end of mail data indication. The first <CRLF> of this
terminating sequence is also the <CRLF> that ends the final line of
the data (message text) or, if there was no mail data, ends the DATA
command itself (the "no mail data" case does not conform to this
specification since it would require that neither the trace header
fields required by this specification nor the message header section
required by RFC 5322 [4] be transmitted). An extra <CRLF> MUST NOT
be added, as that would cause an empty line to be added to the
message. The only exception to this rule would arise if the message
body were passed to the originating SMTP-sender with a final "line"
that did not end in <CRLF>; in that case, the originating SMTP system
MUST either reject the message as invalid or add <CRLF> in order to
have the receiving SMTP server recognize the "end of data" condition.
The custom of accepting lines ending only in <LF>, as a concession to
non-conforming behavior on the part of some UNIX systems, has proven
to cause more interoperability problems than it solves, and SMTP
server systems MUST NOT do this, even in the name of improved
robustness. In particular, the sequence "<LF>.<LF>" (bare line
feeds, without carriage returns) MUST NOT be treated as equivalent to
<CRLF>.<CRLF> as the end of mail data indication.
Receipt of the end of mail data indication requires the server to
process the stored mail transaction information. This processing
consumes the information in the reverse-path buffer, the forward-path
buffer, and the mail data buffer, and on the completion of this
command these buffers are cleared. If the processing is successful,
the receiver MUST send an OK reply. If the processing fails, the
receiver MUST send a failure reply. The SMTP model does not allow
for partial failures at this point: either the message is accepted by
the server for delivery and a positive response is returned or it is
not accepted and a failure reply is returned. In sending a positive
"250 OK" completion reply to the end of data indication, the receiver
takes full responsibility for the message (see Section 6.1). Errors
that are diagnosed subsequently MUST be reported in a mail message,
as discussed in Section 4.4.
When the SMTP server accepts a message either for relaying or for
final delivery, it inserts a trace record (also referred to
interchangeably as a "time stamp line" or "Received" line) at the top
of the mail data. This trace record indicates the identity of the
host that sent the message, the identity of the host that received
the message (and is inserting this time stamp), and the date and time
the message was received. Relayed messages will have multiple time
stamp lines. Details for formation of these lines, including their
syntax, is specified in Section 4.4.
Additional discussion about the operation of the DATA command appears
in Section 3.3.
Syntax:
data = "DATA" CRLF
4.5.2. Transparency
Without some provision for data transparency, the character sequence
"<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
In general, users are not aware of such "forbidden" sequences. To
allow all user composed text to be transmitted transparently, the
following procedures are used:
o Before sending a line of mail text, the SMTP client checks the
first character of the line. If it is a period, one additional
period is inserted at the beginning of the line.
o When a line of mail text is received by the SMTP server, it checks
the line. If the line is composed of a single period, it is
treated as the end of mail indicator. If the first character is a
period and there are other characters on the line, the first
character is deleted.
...
Your DATA command needs to account for that:
Your doit() function is expecting a response after sending a string. That is the wrong logic to use while sending the email data. You can't read a response until after the final terminating <CRLF>.<CRLF> has been sent.
you have to apply transparency to any line in the email that begins with a . character.
With that said, try something more like this:
int readLine(int sock, string &line)
{
// read a line from sock until CRLF is reached.
// I leave this as an exercise for you to implement...
line = ...;
return -1 on error, else 0;
}
int readResponse(int sock)
{
// Please read RFC 5321 section 4.2 for the PROPER format
// of an SMTP response. You should be reading from the
// socket until you receive the terminating
// "Reply-code [ SP textstring ] CRLF" line...
string line;
int r = readLine(sock, line);
if (r < 0) return r;
string code = line.substr(0, 3);
string text = line.substr(4);
if ((line.length() >= 4) && (line[3] = '-'))
{
do
{
r = readLine(sock, line);
if (r < 0) return r;
text += (" " + line.substr(4));
}
while (line.compare(0, 4, code+"-") == 0);
}
cout << code << ": " << text << endl;
return stoi(code);
}
int sendText(int sock, const string &arg)
{
const char *p = arg.c_str();
int len = arg.length();
while (len > 0)
{
int r = write(sock, p, len);
if (r <= 0) return -1;
p += r;
len -= r;
}
return 0;
}
int sendCmd(int sock, const string &arg)
{
int r = sendText(sock, arg + "\r\n");
if (r < 0) return r;
return readResponse(sock);
}
int main(int argc, char *argv[])
{
// Make a socket
int sock = MakeSocket(argv[1], argv[2]);
cout << "socket is " << sock << endl;
assert(sock != -1);
// Begin dialogue
// read the server greeting first...
if (readResponse(sock) != 220) {
// failed, do something...
}
if (sendCmd(sock, "HELO " + org.substr(org.find("#") + 1)) != 250) {
// failed, do something...
}
if (sendCmd(sock, "MAIL FROM: <" + org + ">") != 250) {
// failed, do something...
}
int r = sendCmd(sock, "RCPT TO: <" + dest + ">");
if ((r != 250) && (r != 251)) {
// failed, do something...
}
if (sendCmd(sock, "DATA") != 354) {
// failed, do something...
}
//User writes email here
while (true) {
string line;
getline(cin, line);
// A line consisting of only "." is a valid line in an email
// message, so you should not use that as a terminator in your
// input, use something else, like an EOF marker, or CTRL-C,
// or something...
if (some termination condition)
break;
// DO NOT call readResponse() here!
if (!line.empty() && (line[0] == '.')) {
if (sendText(sock, ".") < 0) {
// failed, do something...
}
}
if (sendText(sock, line) < 0) {
// failed, do something...
}
if (sendText(sock, "\r\n") < 0) {
// failed, do something...
}
}
// NOW call readResponse() here!
if (sendCmd(sock, ".") != 250) {
// failed, do something...
}
sendCmd(sock, "QUIT");
close(sock);
return 0;
}

POCO json POST_METHOD returns results but gives I/O exception and ends program

Hi im havng a problem with poco under linux, im making a https json post to a webserver and im getting the response as i expected.
The problem is that i get an error after the response is printed and it ends the execution of my program.
Here is what i get on console:
200 OK
"{\"test_results\": ["result1", "result2", "result3", "result4"]}"
terminate called after throwing an instance of 'Poco::IOException' what(): I/O error
Here is the code that make the above result to be printed:
int posTry(){
try
{
// prepare session
Poco::Net::Context::Ptr context = new Poco::Net::Context(Poco::Net::Context::CLIENT_USE, "", "", "", Poco::Net::Context::VERIFY_NONE, 9, false, "ALL:!ADH:!LOW:!EXP:!MD5:#STRENGTH");
Poco::URI uri("https://someURL/somePATH");
Poco::Net::HTTPSClientSession session(uri.getHost(), uri.getPort(), context);
// prepare path
std::string path(uri.getPathAndQuery());
if (path.empty()) path = "/";
// send request
std::string test = "{Some json code to get results that is already working}";
Poco::Net::HTTPRequest req(Poco::Net::HTTPRequest::HTTP_POST, path, Poco::Net::HTTPMessage::HTTP_1_1);
req.setContentType("application/json");
req.setKeepAlive(true);
req.setContentLength( test.length() );
session.sendRequest(req) << test;
// get response
Poco::Net::HTTPResponse res;
std::cout << res.getStatus() << " " << res.getReason() << std::endl;
// print response
std::istream &is = session.receiveResponse(res);
Poco::StreamCopier::copyStream(is, std::cout);
std::vector<Poco::Net::HTTPCookie> cookies;
res.getCookies( cookies );
}
catch( const Poco::Exception& e )
{
std::cerr << e.displayText() << std::endl;
}
catch (...)
{
std::cout << "error";
return -1;
}
return 0;
}
I don't know what is this error about and I can't even catch the error in (...) and make the program continue. Can someone help me?
The exception comes from the destructor of Poco::Net::HTTPSClientSession,
This is a known bug fixed in POCO release 1.4.2.
source: http://pocoproject.org/docs/99100-ReleaseNotes.html
If you cannot upgrade, you should be able to get rid of the exception by adding a specific catch for it.

Receiving only necessary data with C++ Socket

I'm just trying to get the contents of a page with their headers...but it seems that my buffer of size 1024 is either too large or too small for the last packet of information coming through...I don't want to get too much or too little, if that makes sense. Here's my code. It's printing out the page just fine with all the information, but I want to ensure that it's correct.
//Build HTTP Get Request
std::stringstream ss;
ss << "GET " << url << " HTTP/1.0\r\nHost: " << strHostName << "\r\n\r\n";
std::string req = ss.str();
// Send Request
send(hSocket, req.c_str(), strlen(req.c_str()), 0);
// Read from socket into buffer.
do
{
nReadAmount = read(hSocket, pBuffer, sizeof pBuffer);
printf("%s", pBuffer);
}
while(nReadAmount != 0);
nReadAmount = read(hSocket, pBuffer, sizeof pBuffer);
printf("%s", pBuffer);
This is broken. You can only use the %s format specifier for a C-style (zero-terminated) string. How is printf supposed to know how many bytes to print? That information is in nReadAmount, but you don't use it.
Also, you call printf even if read fails.
The simplest fix:
do
{
nReadAmount = read(hSocket, pBuffer, (sizeof pBuffer) - 1);
if (nReadAmount <= 0)
break;
pBuffer[nReadAmount] = 0;
printf("%s", pBuffer);
} while(1);
The correct way to read an HTTP reply is to read until you have received a full LF-delimited line (some servers use bare LF even though the official spec says to use CRLF), which contains the response code and version, then keep reading LF-delimited lines, which are the headers, until you encounter a 0-length line, indicating the end of the headers, then you have to analyze the headers to figure out how the remaining data is encoded so you know the proper way to read it and know how it is terminated. There are several different possibilities, refer to RFC 2616 Section 4.4 for the actual rules.
In other words, your code needs to use this kind of structure instead (pseudo code):
// Send Request
send(hSocket, req.c_str(), req.length(), 0);
// Read Response
std::string line = ReadALineFromSocket(hSocket);
int rescode = ExtractResponseCode(line);
std::vector<std::string> headers;
do
{
line = ReadALineFromSocket(hSocket);
if (line.length() == 0) break;
headers.push_back(line);
}
while (true);
if (
((rescode / 100) != 1) &&
(rescode != 204) &&
(rescode != 304) &&
(request is not "HEAD")
)
{
if ((headers has "Transfer-Encoding") && (Transfer-Encoding != "identity"))
{
// read chunks until a 0-length chunk is encountered.
// refer to RFC 2616 Section 3.6 for the format of the chunks...
}
else if (headers has "Content-Length")
{
// read how many bytes the Content-Length header says...
}
else if ((headers has "Content-Type") && (Content-Type == "multipart/byteranges"))
{
// read until the terminating MIME boundary specified by Content-Type is encountered...
}
else
{
// read until the socket is disconnected...
}
}

Blackberry: Java app calling webservice through blackberry enterprise server

I have an java app for blackberry, created with Java Plug-in for Eclipse. I want to invoke a webservice on a webserver through Blackberry mds. The code I am using works, but is not stabile. Meaning that I get successfully get in contact with web server 100 times in a row, but after a while, the connection is broken. The log files from Blackberry are many and not easy to read, but at least I a feel that the phrase "Invalid socket" is not good for me.
I am using StreamConnection class in my code, but I see from some sample code that httpConnection is used instead. Anyone know when to use HttpConnection instead of StreamConnection?
I paste my code here. Perhaps some of you see anything I should have done different:
private boolean sendStatusMessage(String phoneNumber, String status) {
StreamConnection conn = null;
OutputStream output = null; //mari added
try {
String body = "<soapenv:Envelope xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:i3w=\"http://I3WebAction\">"
+ "<soapenv:Header/>"
+ "<soapenv:Body>"
+ "<i3w:I3SetMobileStatus><i3w:p_Status>"
+ status
+ "</i3w:p_Status><i3w:p_PhoneNumber>"
+ phoneNumber
+ "</i3w:p_PhoneNumber>"
+ "</i3w:I3SetMobileStatus></soapenv:Body></soapenv:Envelope>";
String URL = "socket://" + soapServer + ":" + port
+ ";deviceside=false";
conn = (StreamConnection) Connector.open(URL);
//OutputStream output = conn.openOutputStream();
output = conn.openOutputStream();
OutputStreamWriter writer = new OutputStreamWriter(output);
writer.write("POST /SOAPListener/I3SOAPISAPIU.dll HTTP/1.1\r\n");
writer.write("Accept-Encoding: gzip,deflate\r\n");
writer.write("Content-Type: text/xml;charset=UTF-8\r\n");
writer.write("SOAPAction: \"http://I3WebAction/I3SetMobileStatus\"\r\n");
writer.write("User-Agent: Jakarta Commons-HttpClient/3.1\r\n");
writer.write("Host: lvkdb01\r\n");
writer.write("Content-Length: " + body.length() + "\r\n");
writer.write("\r\n");
writer.write(body);
writer.flush();
writer.close(); //mari added
} catch (Exception e) {
Dialog.alert(e.getMessage());
return false;
} finally {
try {
// Close stream regardless of exceptions and return-points
output.close();
} catch (IOException e) {
// If closing the stream causes exception, the stream is most
// likely not open or available. We display an error message,
// and continues the program.
Dialog.alert(e.getMessage());
return false;
}
try {
// Close stream regardless of exceptions and return-points
conn.close();
} catch (IOException e) {
// If closing the stream causes exception, the stream is most
// likely not open or available. We display an error message,
// and continues the program.
Dialog.alert(e.getMessage());
return false;
}
}
return true;
}
I appreciate any comments or ideas on why this code is not running stabile.
By default all requests through BES are transcoded. Try to turn off transcoding and see if that resolves your issue. To turn off transcoding you would need to pass the below header.
Turn off MD transcoding: ("x-rim-transcode-content", "none) as a header
MDS logs would be useful(default location c:\Program Files\Research In Motion\BlackBerryEnterprise Server\Logs)/
They end with “MDAT”. The logging level can be changed by following these instructions.
http://docs.blackberry.com/en/admin/deliverables/14334/Change_logging_level_for_MDSCS_552126_11.jsp
You may also way to enable Verbose HTTP logging for testing, found here, which can help trace through the http messages.
http://docs.blackberry.com/en/admin/deliverables/14334/Change_activities_MDSCS_writes_to_log_827932_11.jsp