Upload file using wininet in c++.

[Azeem Haider]

I'm going to upload text file using c++. I'm using this code but this is not working and there is no error in this code. can you give me suggestion why this is not working?
Here is code.

#include "stdafx.h"
#include "iostream"
#include "windows.h"
#include "wininet.h"
#include "tchar.h"
#include "iostream"
#include "string"
#include "sstream"

#pragma comment(lib, "ws2_32.lib")
#pragma comment(lib, "Wininet.lib")

using namespace std;
// Wininet.lib
// ws2_32.lib
int main(){

TCHAR hdrs[] = _T("Content-Type: multipart/form-data; boundary=---------------------------7d82751e2bc0858");
TCHAR frmdata[] = _T("-----------------------------7d82751e2bc0858\r\nContent-Disposition: form-data; name=\"uploadedfile\"; filename=\"C:\\test.txt\"\r\nContent-Type: text/plain\r\n\r\nfile contents here\r\n-----------------------------7d82751e2bc0858--\r\n");
//char frmdata[] = "...";

LPCTSTR accept[] = {_T("*/*"), NULL};

HINTERNET hSession = InternetOpen(_T("MyAgent"), INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0);
HINTERNET hConnect = InternetConnect(hSession, _T("localhost"), INTERNET_DEFAULT_HTTP_PORT, NULL, NULL, INTERNET_SERVICE_HTTP, 0, 1);
HINTERNET hRequest = HttpOpenRequest(hConnect, _T("POST"), _T("cpp/uploadfile.php"), NULL, NULL, accept, 0, 1);
BOOL sent = HttpSendRequest(hRequest, hdrs, _tcslen(hdrs), frmdata, _tcslen(frmdata));
//BOOL sent = HttpSendRequest(hRequest, hdrs, _tcslen(hdrs), frmdata, strlen(frmdata));

if(hSession==NULL)
{
cout<<"Error: InternetOpen";
}
if(hConnect==NULL)
{
cout<<"Error: InternetConnect";
}
if(hRequest==NULL)
{
cout<<"Error: HttpOpenRequest";
}
if(!sent)
{
cout<<"Error: HttpSendRequest";
}

DWORD status;
DWORD statusLength = sizeof(status);
HttpQueryInfo(hRequest, HTTP_QUERY_STATUS_CODE | HTTP_QUERY_FLAG_NUMBER, &status, &statusLength, nullptr);
if (status != HTTP_STATUS_OK) {
cout << "HTTP status: " << status << endl;
}

//close any valid internet-handles
InternetCloseHandle(hSession);
InternetCloseHandle(hConnect);
InternetCloseHandle(hRequest);


return 0;

}

Here is php file code.

<?php
move_uploaded_file($_FILES["uploadedfile"]["tmp_name"], "/FileFolder/");
?>
Thanks for your time.

[Geoff]

You are evaluating success/failure returns but you are not examining
the reasons why in the case error is returned. Use GetLastError() to
find out why the upload failed.

Insert this after your success tests:

cout << endl << "Error returned was " << GetLastError() << endl;

> DWORD status;
> DWORD statusLength = sizeof(status);

>...

Then interpret the error code for the cause.

NOTE: This is _minimal_ evaluation of the errors. It's entirely
possible that more than one error is happening. (e.g., hConnect ==
NULL AND hRequest == NULL) You need to evaluate GetLastError at each
point where an error might occur so that it returns the correct error
code at each point of failure. Your current scheme only knows a
failure has happened, it does nothing to diagnose the reason(s).

[Geoff]

On Fri, 3 Apr 2015 06:17:29 -0700 (PDT), Azeem Haider
<abclogi...@gmail.com> wrote:

This would certainly be a more robust way to find out why your upload
is failing:

...

if(hSession==NULL)
{
cout << "Error: InternetOpen" << endl;
cout << "Error returned was " << GetLastError() << endl;
}
if(hConnect==NULL)
{
cout << "Error: InternetConnect" << endl;
cout << "Error returned was " << GetLastError() << endl;

}
if(hRequest==NULL)
{
cout << "Error: HttpOpenRequest" << endl;
cout << "Error returned was " << GetLastError() << endl;
}
if(!sent)
{
cout << "Error: HttpSendRequest" << endl;
cout << "Error returned was " << GetLastError() << endl;
}
...

[R.Wieser]

Geof,

> You are evaluating success/failure returns but you are not
> examining the reasons why in the case error is returned.

There is nothing to examine, as the OP stated that :

> > ... there is no error in this code.

In other words: though no doub well ment, your suggestion does nothing in
regard to helping the OP to find the cause of his current problem.

Also notice that there is a distinct possibility that the posted is a "quick
and dirty" test only, not at all a finished version (a big hint might be
that the code just sends "contents here" instead of a real textfile).


To the OP:
What makes you sure that the problem is in the code you posted, and not in,
for example, the headers you created or in the way Apache/PHP handles the
incoming request ? Maybe it just doesn't actually move the file to the
destination folder ? Maybe it doesn't even reach the PHP script at all
(gets discarded by Apache).

Suggestion: Check both sides of the equation:

1) check if the actual send data is comparable to what a simple browser
would send (possibly displaying, at the server side, the received HTTP
request as raw data, headers as well as body)

2) Also send the request from the above "simple browser" to the server
running that PHP script of yours and see if gets accepted. If not it might
be an indication that the receiving end is flawed, not your program (the
sending side).

If it does get accepted, see if your program can exactly mimic that "simple
browser" request and see what happens.

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws
7ijthap5fri7vq1u5...@4ax.com...

> On Fri, 3 Apr 2015 06:17:29 -0700 (PDT), Azeem Haider
> <abclogi...@gmail.com> wrote:
>
> >I'm going to upload text file using c++. I'm using this code but
> >this is not working and there is no error in this code. can you
> >give me suggestion why this is not working?
> >Here is code.

[Big snip]

> You are evaluating success/failure returns but you are not
> examining the reasons why in the case error is returned.
> Use GetLastError() to find out why the upload failed.

[Snip some more]

[Geoff]

Rudy,

On Sat, 4 Apr 2015 12:50:30 +0200, "R.Wieser" <add...@not.available>
wrote:

>> You are evaluating success/failure returns but you are not
>> examining the reasons why in the case error is returned.
>
>There is nothing to examine, as the OP stated that :
>
>> > ... there is no error in this code.
>

I took him to mean "the code compiles without errors". I have
confirmed this by copy-pasting his code and it does, in fact, compile
without errors or warnings. This does NOT mean the code "executes
without failure" since if that were true he would not be asking "why
this is not working?".

I actually took the time to compile and test his code. My suggestions
were based on those tests.

>In other words: though no doub well ment, your suggestion does nothing in
>regard to helping the OP to find the cause of his current problem.

The deficiency of his code is that he catches pass/fail from the API
functions with his tests for NULL but he doesn't use GetLastError to
find the cause of failures at the points in the code where they occur.
I also got the impression that he's not debugging or stepping through
his code and examining the state of his program as it executes.

He's left with a program that tells him it failed and at what stage it
failed but it doesn't tell him why it failed.

The API functions he's using can and do fail for many reasons and they
are documented to provide the error code that GetLastError returns. He
will be much better off if he uses GetLastError and once he sees error
codes like "Error: HttpSendRequest Error returned was 12029 HTTP
status: 0 " or "HTTP status: 404", he will gain deeper understanding
of where and why his program is failing.

If I were writing this, I would evaluate the success/failure of each
API call and the error code from GetLastError at each step to prevent
cascade failure.

For example, in the OP's program InternetConnect() depends on hSession
not being NULL from the InternetOpen() call that precedes it and
HttpOpenRequest() request depends on hConnect not being NULL from the
InternetConnect() call that precedes it and HttpSendRequest() depends
on hRequest not being NULL from the HttpOpenRequest() that precedes
it.

A NULL return value at any one of those points invalidates the
subsequent API calls and he would have been better off not performing
them at all and returning the error report at the first error.

His evaluation and display of the results later down the line is now
dependent on evaluating them and outputting them in the same order
that the API functions were called so if he (or a maintainer) changes
the order of his failure tests, they will display erroneous results.

[R.Wieser]

Geof,

> I took him to mean "the code compiles without errors".

Just one question: why do you think the OP would be smart enough to include
checks in his code to signal failure, but dumb enough to forget mentioning
running his program showing them ?

As for *how* he wrote his code ? Thats a whole other discussion, and has
nothing to do with his current problem. But I agree, I wouldn't do it like
that myself either. Though as I mentioned earlier, his posted code is most
likely testing only.

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

e130iah8c61jgir9e...@4ax.com...

[R.Wieser]

Azeem,

I've just tried your code, and did not get any errors (though I've used a
different language, so I'm not a 100% sure).

I would suggest to follow the HttpSendRequest by an InternetReadFile so you
can retrieve the webservers response (catching *their* error messages).

Here I got an error back in the $_FILES array (use "echo print_r($_FILES);"
to show its contents. I've not investigated further (thats your job :-) )

Regards,
Rudy Wieser


-- Origional message:

Azeem Haider <abclogi...@gmail.com> schreef in berichtnieuws
d7760604-5fd8-4c80...@googlegroups.com...

I'm going to upload text file using c++. I'm using this code but this is not
working and there is no error in this code. can you give me suggestion why
this is not working?
Here is code.

[Snip code listing]

Thanks for your time.

[Deanna Earley]

On 03/04/2015 14:17, Azeem Haider wrote:
> I'm going to upload text file using c++. I'm using this code but this
> is not working and there is no error in this code. can you give me
> suggestion why this is not working?

With issues like this, when asking for help, it's usually a good idea to
give some description of what IS happening and how it's not working as
you expect.
Which bit isn't it doing and what are you expecting that isn't happening?

All if this is preferable to a "my code doesn't work, can you tell me why?"

--
Deanna Earley (d...@earlsoft.co.uk, d...@doesnotcompute.co.uk)

(Replies direct to my email address will be printed, shredded then fed
to the rats. Please reply to the group.)

[Geoff]

On Sat, 4 Apr 2015 20:37:33 +0200, "R.Wieser" <add...@not.available>
wrote:

>Just one question: why do you think the OP would be smart enough to include
>checks in his code to signal failure, but dumb enough to forget mentioning
>running his program showing them ?

Because he originally posted this exact question in comp.lang.c++ and
was told to seek help elsewhere and he ended up here. He clearly sees
nothing wrong with his code as such and was looking for new eyes and
advice. I do not know if he posted it anywhere else. Perhaps you can
search for the title in Google groups and find more of them.

The English language is clearly not his first language and he posted
the absolute minimum to get his point across. He used the phrase "I'm
using this code but this is not working" and that means he's tried it
and it doesn't work. I interpret "work" to mean "It doesn't upload the
file and it doesn't tell me why it fails." Yes, apparently, he's dumb
enough not to include his program output to show where it's failing
for him.

I don't care if this is production code or only test code. The code
posted is fine except for the error handling and my point was that if
it fails in test then he should use more error diagnostics to let the
program tell him more about why it's failing. If it's copy-pasted from
the production code then I would expect it to have had more extensive
error handling.

I wish to point out that _I_ never said anything about how smart or
dumb the OP was, _you_ did.

Since the OP has not replied to this thread to indicate he's seen our
advice, I deem the subject closed and I won't be spending any more
time on it.

[R.Wieser]

> Azeem,

(use "echo print_r($_FILES);"

I made a mistake here: Its either just "print_r($_FILES);" (print to
standard output) or "echo print_r($_FILES,true);" (The "true" makes the
print_r() return a string, which can than be echoed -- or used to write to a
file).

Regards,
Rudy Wieser


-- Origional message:

R.Wieser <add...@not.available> schreef in berichtnieuws
55204769$0$2848$e4fe...@news2.news.xs4all.nl...

[R.Wieser]

Geoff,

> I interpret "work" to mean "It doesn't upload the
> file and it doesn't tell me why it fails."

Yep, thats exactly what I mean. Why did you interpret it like that, when
there are a few more possibilities to consider ? Why not interpret it as
"I'm not getting the result I expect, and I don't know why" ?

You've been second-guessing the OP (why not simply ask him to give a bit
more info, like Deanna did ?), and have tailored your answer as such. What
now if Azeems "there is no error in this code" means exactly that (no errors
while compiling, none when running the code) ?

Yes, I considered the same as you did, the OP simply forgot to tell us his
program threw an error. But what now if his program didn't ?

So my suggestions catered to both. If his program actually did fail he will
not be able to get his webserver to display any raw data. If his program
actually did send the request, the raw data is the first step in the next
phase of checking. :-)

See the difference between your and my approach ?

> I wish to point out that _I_ never said anything about how
> smart or dumb the OP was, _you_ did.

Neither did I. The words where used to describe the relative weight of two
possible actions in relation to each other, not an absolute designation of
anything/anyone.

And no, although you did not *say* anything about it, your did choose to
assume the OP made an omission in his post. Why ? Why did you go out for
the worst ? Most likely not because you consider the OP to be "smart" (or
whatever word you like to use in its place to describe the OPs knowledge,
insight, etc).

> Yes, apparently, he's dumb enough not to include his program

> output.

Oh blimy! You really did use the word "dumb" there! In relation to the OP
no less. So yes, you did say it.

And again you *still* presume that the program generated any output to post.
Even though his posted code, as you can see for yourself, doesn't output
*anything* when all checks pass. In other words, you expect the OP to
include his programs output *were there is none to be had*. Now who's
"dumb" here ? :-)

> Since the OP has not replied to this thread to indicate he's
> seen our advice, I deem the subject closed and I won't be
> spending any more time on it.

Hmmm ... The thread is not even 48 hours old, and going into an easter
weekend. I don't think I will consider it closed just yet.

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

jkp0iapbfi57eq42h...@4ax.com...

[Geoff]

On Sun, 5 Apr 2015 10:43:36 +0200, "R.Wieser" <add...@not.available>
wrote:

>And again you *still* presume that the program generated any output to post.
>Even though his posted code, as you can see for yourself, doesn't output
>*anything* when all checks pass. In other words, you expect the OP to
>include his programs output *were there is none to be had*. Now who's
>"dumb" here ? :-)

The fact it doesn't output anything to the console is the fault of his
form of error reporting. (He would have been better off, if this is
test code, to trace his pass/fails unconditionally.)

There are at least two output streams to consider.
1. The console
2. The socket to the HTTP server.

Optionally:
3. The stderr output stream.

All would be needed to ascertain the true nature of the fault and the
OP, being the expert on his code ought to be in the best position to
provide those data.

As it is, I sniffed the wire on the interaction with the HTTP server
and major flaw in his code is that the HTTP POST is malformed and,
as-written, the code cuts off the frmdata string before the full form
data is emitted on the POST, it's cut off at "...filename=".

If you read the MSDN documentation _CLOSELY_ you will discover that
dwHeadersLength is specified in TCHARs but dwOptionalLength is
specified in BYTES. Therefore the user must compute the number of
octets to emit, not the length of the _T-string in frmdata. Since the
dwOptionalLength specifies the length of the data on the network side
of the protocol, the MSDN documentation of this function is flawed by
not boldfacing that term and by not calling it OCTETS rather than
bytes.

Modifying the HttpSendRequest to read:

BOOL sent = HttpSendRequest(hRequest, hdrs, _tcslen(hdrs),

frmdata, _tcslen(frmdata) * sizeof(TCHAR));

causes the program to emit the full POST request with the correct
number of octets.

My critique of the error handling in his posted code still stands. The
HTTP 200 OK status reflects the successful transmission of data, it
says nothing about the form of or validity of that data.

In retrospect, looking at his commented blocks, he's been "guessing"
about where his fault is and was trying to find the flaw in the string
lengths by toying with the strings and their types. Clearly, the
phrase "there is no error in this code" is a false assertion.

As for why it is failing on the server side, CGI scripting is outside
my preferred area of expertise and I gave up doing any more of it in
2001. I also consider CGI scripting to be off-topic for this group. If
you want to delve into it, feel free to do so and advise the OP as you
see fit, I might learn something.

[R.Wieser]

Geoff,

> The fact it doesn't output anything to the console is the
> fault of his form of error reporting.

I quite disagree with you there. Having every error-check output
*something* even though no problem is detected would even make your current
email-reader unworkable (you have pressed a key/moved your mouse, no problem
is detected. Press OK to continue :-) ).

Worse: by doing so you would get "information numbness" and probably miss
the actual error message between the scores of "no problem detected,
continuing" (and variations thereof) messages.

Nope, as far as I'm concerned only displaying something when there actually
is an error is a good choice. Though I would probably have choosen to
include, if only for testing purposes, a terminating "all went OK" message
too.

But again, would using your method of (non-)error reporting change anything
to the OPs problem ? I don't think so.

> There are at least two output streams to consider.
> 1. The console

..

> Optionally:
> 3. The stderr output stream.

Don't you think that outputting a simple "program terminated" text at the
bottom of the program would have been sufficient for such cases ?

And pardon me, but this sounds a bit .... contrived. How many times have
you seen either of those two actually fail, especially with the simple
output the OP is doing ?

> 2. The socket to the HTTP server.

And how would your suggestion to have the OPs program also display the
output of GetLastError() have helped to detected such a problem ?

> All would be needed to ascertain the true nature of the fault

Bull. As you yourself have made clear in the rest of your post.

Also, first inventorizing and testing all possible causes of something -- no
matter how unlikely -- would normally be a big waste of (your bosses) time
(and money).

> and the OP, being the expert on his code ought to be in the
> best position to provide those data.

True. Which your method of helping left no room for. Which was *all* I
actually wanted to say about it ...

> the code cuts off the frmdata string before the full form
> data is emitted on the POST, it's cut off at "...filename=".

Damn ! You mean that my suggestion to the OP to look at what he receives
on his webserver would have directly shown that some *data* he did send was
faulty ? Who would have thought that ... :-p

> My critique of the error handling in his posted code still stands.

Yes, I can't deny that you still keep pressing that. For what reason I
have no idea, but you surely do ...

> The HTTP 200 OK status reflects the successful transmission
> of data, it says nothing about the form of or validity of that data.

May I conclude from the above that the OPs program, as it now is, does
*exactly* what it is told and runs from top to bottom without encountering
any problem ?

Blimy ...

> If you read the MSDN documentation _CLOSELY_ you will
> discover that dwHeadersLength is specified in TCHARs but
> dwOptionalLength is specified in BYTES.

Well, you got me there ... Although, as I default to ANSI, I seldom have
the need to consider it. :-)

On the other hand, TCHARs are not specified as either ANSI or
wide-character: Whats the OP using ? :-p (yeah, I know. I'm again poking
you a bit here. Most likely the OPs compiler uses wide-character).

> the MSDN documentation of this function is flawed by not
> boldfacing that term and by not calling it OCTETS rather
> than bytes.

And, reading that documentation, not mentioning what kind of data (A or W)
the lpOptional parameter accepts. Hmmm, lets check that ...

Yep, another possible problem: The function does send that data unaltered to
the other side. That means that if the compiler "sees" TCHARs as
wide-character the other side will get something it can't handle (it expects
ANSI).

Or to put that differently, the "optional data" should be defined as (ANSI)
chars, not TCHARS. Another documentation ommision if you ask me.

> Modifying the HttpSendRequest to read:
> BOOL sent = HttpSendRequest(hRequest, hdrs, _tcslen(hdrs),
> frmdata, _tcslen(frmdata) * sizeof(TCHAR));
>
> causes the program to emit the full POST request with the
> correct number of octets.

Correct, but still unusable (by the webserver) nonetheless. In other words:
you would be making he problem worse. :-o

On the other hand, I did not know that either and would most likely have
made a mess of it too. I found the above out just now by testing the
function.

> Clearly, the phrase "there is no error in this code" is
> a false assertion.

And water is wet. Your point ?

As far as I know all I did was stating that the program (read, any of the
functions therein) most likely didn't return any error. Besides, if I
really thought that the problem wasn't in what he wrote, I would most likely
have adviced him to find a PHP related newsgroup.

> As for why it is failing on the server side, CGI scripting is outside

> my preferred area of expertise.

As it is quite outside my area of expertise (have only dabbed a few times in
it). But as luck will have it debugging often works the same everywhere:
make sure your input is correct, only than start worrying about how its
manipulated.


Bottom line, apart from the confusion over that optional data argument the
program seems to work as intended.

Azeem Haider, I hope you are reading the above.

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

b7e5ia11t566e71mb...@4ax.com...

[Geoff]

On Tue, 7 Apr 2015 14:38:10 +0200, "R.Wieser" <add...@not.available>
wrote:

>Azeem Haider, I hope you are reading the above.

Nope. He's gone elsewhere and has not found an answer on the web
forums. FWIW, this problem and code nearly identical was posted on the
web forums since 2009.

[Geoff]

On Tue, 7 Apr 2015 14:38:10 +0200, "R.Wieser" <add...@not.available>
wrote:

>> the code cuts off the frmdata string before the full form
>> data is emitted on the POST, it's cut off at "...filename=".
>
>Damn ! You mean that my suggestion to the OP to look at what he receives
>on his webserver would have directly shown that some *data* he did send was
>faulty ? Who would have thought that ... :-p

When the post fails, no data appears on the web server at all.

The only way to observe the sent data that I have found was to sniff
the wire with a packet sniffer.

[Geoff]

On Tue, 7 Apr 2015 14:38:10 +0200, "R.Wieser" <add...@not.available>
wrote:

>> If you read the MSDN documentation _CLOSELY_ you will
>> discover that dwHeadersLength is specified in TCHARs but
>> dwOptionalLength is specified in BYTES.
>
>Well, you got me there ... Although, as I default to ANSI, I seldom have
>the need to consider it. :-)
>
>On the other hand, TCHARs are not specified as either ANSI or
>wide-character: Whats the OP using ? :-p (yeah, I know. I'm again poking
>you a bit here. Most likely the OPs compiler uses wide-character).

Default for Visual Studio projects is Unicode (UTF16) which is why the
OP was having so much trouble trying to figure out his failure mode.
TCHAR is wchar_t in Unicode mode and char in ANSI mode.

Changing it back to ANSI is a matter of resetting the project
character set to "Not set". TCHAR is redefined to char as a result and
the code compiles without altering the source and emits ANSI chars on
the wire. The clue comes from knowing the form submitted must be ANSI,
not UTF.

The code can be rewritten to convert UTF to ANSI for the wire if the
larger project must be Unicode but this example will work if compiled
in ANSI.

I've modified the PHP on the server side to use an appropriate
directory and to send diagnostics back to the client and the program
works successfully, reporting success all along the way. The client
code still doesn't display the received messages from the server
script but I might post a solution later.

<?php

$uploaddir = '../uploads/';
$uploadfile = $uploaddir .
basename($_FILES['uploadedfile']['name']);

echo "<p>";

if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'],
$uploadfile)) {
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "Upload failed";
}

echo "</p>";
echo '<pre>';
echo 'Here is some more debugging info: ';
print_r($_FILES);
print "</pre>";

?>

[R.Wieser]

Geoff,

> When the post fails, no data appears on the web server at all.

Actually, it doesn't fail and it does. The "apache_request_headers()"
shows, by the "content-length" that *something* came in (apart from the
headers themselves I mean). It just doesn't show where its expected, like
in the $_FILES arrays.

... Which is a problem I forsaw and exactly why I suggested the OP to look
at the *raw* data.

> The only way to observe the sent data that I have found
> was to sniff the wire with a packet sniffer

I had no idea that displaying raw data is, from within Apache/PHP, more
difficult than I thought ... Looks to be possible, but not without changing
a number of permanent settings (which I always dislike to do for a one-off
test).

I myself used a small tool I've created some years ago, just accepting the
incoming data and dumping it, in human readable form, into a logfile.

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

b958iad8kp63gh3q3...@4ax.com...

[R.Wieser]

Geoff,

> Default for Visual Studio projects is Unicode (UTF16)

...

> TCHAR is wchar_t in Unicode mode and char in ANSI mode.

Which is pretty-much exactly what I said in my previous message.

> ... which is why the OP was having so much trouble trying

> to figure out his failure mode.

Probably because *he* didn't make any mistakes he could have evaded. All he
did was interpreting the MS documentation the best he could, and assuming
his compiler would translate the TCHAR to the apropriate form where needed.
Both failed him.

Actually, it looks like he read those docs *very* carefully, 'cause he did
try to provide the length of the "optional" data as bytes. Ofcourse, a
strlen() would most likely stop after the first byte (on the second half of
the wide char, which is often Zero). On the other hand, he was smart
enough to figure out that _tcslen() might give him the wrong answer.

> The client code still doesn't display the received messages
> from the server script but I might post a solution later.

As I, at this point, have absolutily *no* idea what you did send and how, so
I cannot respond to it in any way.

As I've mentioned in my previous message, I've did some testing with sending
the request with both A and W style function myself, even posting some
conclusions from it. I would appriciate it if you took the time to respond
to them just as you would like me to respond to yours ...

You see, I get the strong feeling your tests are duplicating mine. Which is
not per se a bad idea if you want to learn from it, but if you only want to
pinpoint the problem a bit of a waste of time.

As for the PHP script ? Also include that function I mentioned in my
previous message:

echo "request headers: ";
print_r(apache_request_headers());

You will see that there definitily is something coming in.

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

lc58ial11l8pvklum...@4ax.com...

[R.Wieser]

Geoff,

> Nope. He's gone elsewhere and has not found an answer
> on the web forums.

Possible, though I have no info to colaborate your above assumption. For
all I know he found the cause of the problem himself and moved on (while
forgetting to inform us about it)..

> FWIW, this problem and code nearly identical was posted
> on the web forums since 2009.

And as long as that MSDN documentation about that HttpSendRequest function
stays as it is and people depend on their compilers to "do the right thing"
we can probably expect a few more of them. After all, what Azeem posted is
pretty-much the minimal implementation of it.

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

r108iah0obi4g5frm...@4ax.com...

[Geoff]

On Wed, 8 Apr 2015 12:19:04 +0200, "R.Wieser" <add...@not.available>
wrote:

>As I've mentioned in my previous message, I've did some testing with sending
>the request with both A and W style function myself, even posting some
>conclusions from it. I would appriciate it if you took the time to respond
>to them just as you would like me to respond to yours ...

If you posted about this and using the A vs. W style functions and the
results you got, I never saw it. I've searched this topic thoroughly
and I have no such message. If you can provide a message-ID perhaps I
can retrieve and read it.

[R.Wieser]

Geoff,

>If you can provide a message-ID perhaps I can retrieve
> and read it.

Its in yesterdays message (Tue, 7 Apr 2015 14:38:10 +0200). But as I did
put it a bit terse its possible it got overlooked. The size of my replies
does not help either I guess.

This is the relevant bit:

[quote]

And, reading that documentation, not mentioning what kind of data (A or W)
the lpOptional parameter accepts. Hmmm, lets check that ...

Yep, another possible problem: The function does send that data unaltered to
the other side. That means that if the compiler "sees" TCHARs as
wide-character the other side will get something it can't handle (it expects
ANSI).

Or to put that differently, the "optional data" should be defined as (ANSI)
chars, not TCHARS. Another documentation ommision if you ask me.

[/quote]

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

t2oaiapm992258hk5...@4ax.com...

[Geoff]

On Tue, 7 Apr 2015 14:38:10 +0200, "R.Wieser" <add...@not.available>
wrote:

>> There are at least two output streams to consider.
>> 1. The console
>..
>> Optionally:
>> 3. The stderr output stream.
>
>Don't you think that outputting a simple "program terminated" text at the
>bottom of the program would have been sufficient for such cases ?
>
>And pardon me, but this sounds a bit .... contrived. How many times have
>you seen either of those two actually fail, especially with the simple
>output the OP is doing ?
>

Not contrived. Your statement, "there is no output" is simply false
since the program has at least 3 output channels and the HTTP output
channel is every bit in need of inspection as the console if you're
going to reach a correct conclusion about where the error occurs, but
I didn't feel at that time that this was the proper place to start
troubleshooting.

Zero compiler errors and warnings does not mean there are no bugs in
the code.

>> 2. The socket to the HTTP server.
>
>And how would your suggestion to have the OPs program also display the
>output of GetLastError() have helped to detected such a problem ?
>
>> All would be needed to ascertain the true nature of the fault
>
>Bull. As you yourself have made clear in the rest of your post.

Output from GetLastError can tell you about whether the API calls were
properly formed or whether there was a socket error. I've lost it in
my record of looking at this code but the original format of his
HttpSendRequest failed for me with error 87 and returned 0. A zero
return value from that call was useless from a diagnostic perspective
at that time.

My point was that production or sample, this program's silence about
error return values caused the OP to assume "this program has no
errors" and there are actually several conceptual, technical,
structural and implementation errors in the program.

As an example for usage of the API functions, it serves as a very bad
one and is very typical of lots of code samples on the web, which
appears to be where he got it.

Even now, the program doesn't do what the OP stated is his intention
for the program. It doesn't UPLOAD a file. It submits a form and that
form creates a file on the server side and places content from the
form into that file.

Based on his original code, the OP originally appears to want to
upload the contents of C:\test.txt to the server at some preexisting
directory on that server. Based on this alone, the program has an
error and that error is that it doesn't perform as intended.

My intent was to get him to re-examine his code and to modify it to
report functional errors within the module and START there.

When I have a program that isn't working as intended I start looking
at variables and I often start by probing the program's progress by
printing out information at different points just to make sure it's
doing the right thing. Visual Studio is an excellent debugger for
that.

Too often I see people write code, compile it, run it, observe it
doesn't work right and then start making changes based on no
information other than guessing, about why they think the program is
malfunctioning. This is what I perceived from the OP's original post
that included commented out lines of code. What I saw was evidence of
compile, run, hack, compile, run, hack; to no successful end.

[Geoff]

On Tue, 7 Apr 2015 14:38:10 +0200, "R.Wieser" <add...@not.available>
wrote:

>Also, first inventorizing and testing all possible causes of something -- no
>matter how unlikely -- would normally be a big waste of (your bosses) time
>(and money).

I don't do that. But I try to use error returns from API functions
correctly as documented and when a program isn't working as intended I
write some probe code to get the machine to tell me what's wrong
instead of staring at the code, with no data to observe, wondering
what's wrong.

I am my own boss and my profit margin is fine, thank you.

[Geoff]

On Wed, 8 Apr 2015 19:39:26 +0200, "R.Wieser" <add...@not.available>
wrote:

>Geoff,
>
>>If you can provide a message-ID perhaps I can retrieve
>> and read it.
>
>Its in yesterdays message (Tue, 7 Apr 2015 14:38:10 +0200). But as I did
>put it a bit terse its possible it got overlooked. The size of my replies
>does not help either I guess.
>
>This is the relevant bit:
>
>[quote]
>And, reading that documentation, not mentioning what kind of data (A or W)
>the lpOptional parameter accepts. Hmmm, lets check that ...
>
>Yep, another possible problem: The function does send that data unaltered to
>the other side. That means that if the compiler "sees" TCHARs as
>wide-character the other side will get something it can't handle (it expects
>ANSI).
>
>Or to put that differently, the "optional data" should be defined as (ANSI)
>chars, not TCHARS. Another documentation ommision if you ask me.
>[/quote]
>
>Regards,
>Rudy Wieser

On this I wholeheartedly agree. If MS were going to write
HttpSendRequest properly, it would properly handle the text handed to
it and convert to network-acceptable octets.

On the other hand, I have no idea whether future HTTP protocol
standards will accept UTF in form data or what a regionalized web
server is supposed to do. What if the form is supposed to accept
Japanese or Chinese? Is there a function in PHP to handle this? I
don't know and I can't take the time to find out.

[Richard Heathfield]

On 08/04/15 18:55, Geoff wrote:
>
> Zero compiler errors and warnings does not mean there are no bugs in
> the code.
>

Actually, that's precisely what it means. Since you clearly know nothing
about the testing phase of the SDLC, here is a quick guide for you. It
will help you in your next job interview.

Unit Test: pass if it compiles;
Link Test: pass if it links;
Integration Test: pass if it executes without crashing, at least three
times in four;
User Acceptance Test: pass if it executes without crashing, at least
three times in four, on the customer's machine;
Regression Test: pass if it executes without crashing, at least three
times in four, on the same machine that it worked on yesterday.

No need to thank me. Being right is its own reward.

Now, how do I get out of here without being lynched?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[Geoff]

On Thu, 09 Apr 2015 02:07:42 +0100, Richard Heathfield
<r...@cpax.org.uk> wrote:

>On 08/04/15 18:55, Geoff wrote:
>>
>> Zero compiler errors and warnings does not mean there are no bugs in
>> the code.
>>
>
>Actually, that's precisely what it means. Since you clearly know nothing
>about the testing phase of the SDLC, here is a quick guide for you. It
>will help you in your next job interview.
>
>Unit Test: pass if it compiles;
>Link Test: pass if it links;
>Integration Test: pass if it executes without crashing, at least three
>times in four;
>User Acceptance Test: pass if it executes without crashing, at least
>three times in four, on the customer's machine;
>Regression Test: pass if it executes without crashing, at least three
>times in four, on the same machine that it worked on yesterday.
>
>No need to thank me. Being right is its own reward.
>
>Now, how do I get out of here without being lynched?

LOL, thanks Richard, I'll make a note of this. :)
Oh, wait, you didn't want a thank you... oh well.

[Deanna Earley]

On 09/04/2015 02:07, Richard Heathfield wrote:
> On 08/04/15 18:55, Geoff wrote:
>>
>> Zero compiler errors and warnings does not mean there are no bugs in
>> the code.
>>
>
> Actually, that's precisely what it means. Since you clearly know nothing
> about the testing phase of the SDLC, here is a quick guide for you. It
> will help you in your next job interview.
>
> Unit Test: pass if it compiles;
> Link Test: pass if it links;
> Integration Test: pass if it executes without crashing, at least three
> times in four;
> User Acceptance Test: pass if it executes without crashing, at least
> three times in four, on the customer's machine;
> Regression Test: pass if it executes without crashing, at least three
> times in four, on the same machine that it worked on yesterday.

Well, my code is currently passing just the "Link test". :(
I'm trying to figure out why WinInet keeps returning
ERROR_INTERNET_TIMEOUT on a stream that's still receiving data...

[R.Wieser]

Geoff,

> Not contrived. Your statement, "there is no output" is
> simply false

Only if you want to pull it out of context. You see, we where talking
about capturing errors there. And those simply did not appear.

> and the HTTP output channel is every bit in need of inspection

The HTTP output *channel* , or what emits ?

If you mean the first, why ? Why (again) try to "go deep" when a "surface
check" (looking at what output from the program/gets send to the server)
will give you pretty-much everything you need ?

> Zero compiler errors and warnings does not mean there are
> no bugs in the code.

Correct. But why are you bringing this up again ? I thought we had
already progressed to "Zero compiler errors and warnings" *and* "no errors
while running the program" ...

> Output from GetLastError can tell you about whether the API
> calls were properly formed or whether there was a socket error.

Nope. Or, if you use it that way you're doing it wrong. For multiple
reasons.

> My point was that production or sample, this program's
> silence about error return values caused the OP to assume
> "this program has no errors" and there are actually several
> conceptual, technical, structural and implementation errors
> in the program.

And all *I* see is some "testing only" code (what, did I only mention that
for the sixt time?) with a single mistake (misinterpreting of unclear
documentation actually) which stopped it from functioning. In other words,
I have no idea what you're talking about.

> As an example for usage of the API functions, it serves as a very
> bad one

How the f*ck did you come to the conclusion that it was posted as an example
? For gods sake, the OP even mentioned that it does not even work !

> Even now, the program doesn't do what the OP stated is
> his intention for the program. It doesn't UPLOAD a file.

Even though that is debatable, the OP never claimed his program would do
that. He said that "I'm going to upload text file using c++", not that his
posted code would be doing it (how's that for pedantic ?).

> Based on this alone, the program has an error and
> that error is that it doesn't perform as intended.

A description which would make any politician proud: It seems to be
meaningfull, while not actually saying anything at all. :-\

> My intent was to get him to re-examine his code and
> to modify it to report functional errors within the module
> and START there.

Sigh ... As much as you stubbornly keep refusing to believe it, there were
*no* functional errors. There is nothing *to* report.

As you most likely already have found out from your own tests I might add.

> When I have a program that isn't working as intended I start
> looking at variables and I often start by probing the program's
> progress by printing out information at different points just to
> make sure it's doing the right thing.

Not when you have output to look at and able to make some conclusions from
it before "going deeper".

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

qnoaialbcpga6r1d1...@4ax.com...

[R.Wieser]

Geoff,

> ... instead of staring at the code, with no data to observe,
> wondering what's wrong.

I think we need to terminate our conversation.

Although the above is true I've mentioned several times that that there
actually is data to observe, and which you indeed have observed (using a
sniffer).

I think its obvious that you have your method, and I have mine. We do not
look eye-to-eye in that regard. Lets leave it at that, shall we ?

> I am my own boss and my profit margin is fine, thank you.

As if that is what I tried to convey ... :-(

Oh by the way: I found the problem without using any debugger at all.
Simply by looking at the send raw data (as received by a "server") and
concluding from that. A few changes to the code / looking at the raw data
was sufficient to figure out what was going on and determine the point and
type of failure. As I already posted.

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

9tqaia9t48bilcep1...@4ax.com...

[Geoff]

On Thu, 9 Apr 2015 11:34:17 +0200, "R.Wieser" <add...@not.available>
wrote:

>> As an example for usage of the API functions, it serves as a very
>> bad one
>
>How the f*ck did you come to the conclusion that it was posted as an example
>? For gods sake, the OP even mentioned that it does not even work !

Because code almost identical to this was posted on stack overflow in
2009 and it was a different person questioning the functionality. It
is clear that Azeem got it from a common place of origin and the code
is not unique to him nor is it his own code.

Its form and structure, along with the fact it contains the line
"using namespace std;", which is cargo cult among novices and textbook
examples, tells me this code was most likely lifted from a book or a
class or a web example somewhere and he's trying to adapt and use it.

But you're so brilliant and so insightful that your first order of
business, before even answering the original OP's question in your own
manner and let it stand on it's own merit, is to criticize someone
else's answer and start a completely irrelevant discussion about why
you're brilliant and insightful answer is the only correct solution to
any problem.

Yes, our discussion is over. Again.

[R.Wieser]

Geoff,

> Because code almost identical to this was posted on stack
> overflow in 2009 and it was a different person questioning
> the functionality.

And I already told you what I thought about that. You refused to respond to
it, but now again bring it up as some "new" statement. What do you want to
happen ? Do you expect me to slip up and agree to it ? Is it *that* much
worth to you that you keep trying ?

Besides, how *can* I agree with you, as all I have is your "I've seen it"
statement.

Oh by the way: Why that "somewhere in 2009" reference ? A quick google
just now shows *many* of the same kind, from all over the world. All with
the same problem. Just as I already said there would probably be ...

And copy one of those "examples" when they have been posted as having a
problem themselves ? Not bloody likely.

> But you're so brilliant and so insightful that your first order of

> business, ... , is to criticize someone else's answer.

I told you why in that same message. But to repeat it here in short form:
you did put your presumptions over what Azeem told us, and suggested him to
do stuff which, if he was correct and you where not, would be *absolutily
worthless* (or even worse!) to solve his problem. And you did not even
bother to inform him of that.

And Azeem was right, his code did not return any error. As you, a while
later, did find out for yourself ...

> ... and start a completely irrelevant discussion about why

> you're brilliant and insightful answer is the only correct
> solution to any problem.

Really ? I did that ? With you trying to do your best to stop me no doubt.
:-)

And I never said that it would be "the only correct solution", nor that it
would be "to any problem." Being disingenuous again ?

I however *did* state something along the lines of going for the easiest to
check things first using the simpelest tools would be a good idea. I
*tried* to show you a method which you could possibly benefit from.

But no. Though you did look at the raw data you did not see anything you
could use, and (therefore) ignored it.

As for "the only correct solution" ? I think you are the one who kept
pushing that debugger as "the" solution to almost(?) anything.

In other words: I could say that *you* are the one guilty of what you accuse
*me* of (a long winded way to say "pot, meet kettle"). Funny, no ?

As for that debugger being able to solve it ? Only if you would know that
certain strings needed to have a different type than other ones, which your
suggestion to multiply the "_tcslen(frmdata)" by two shows you had, at some
time during your bug bhunting, no clue of. You would have seen a
wide-character frmdata string, and considered it to be good. Making you
none the wiser ...

My old teacher always said, "Measuring is knowing, but only if you know what
you are measuring".

And me being "brilliant and insightful" ? Most likely its just experience
speaking, having a few decades of it.

Having said that, whats your problem ? You've tried to pull stuff outof
context, put words into my mouth and a few things of that more. In short,
you've tried to manipulate the heck outof me. Why ? Are you that
hell-bent on always having the upper hand ? Even if you have to cheat for
it ? Do you think that if it would have worked your "victory" would have
had any meaning ?

> Yes, our discussion is over. Again.

Yes, we had one. Upto a point. Or at least, I thought we had. After that
... not so much.

Oh well.

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

3hedialn5nqab94up...@4ax.com...

[Geoff]

On Fri, 10 Apr 2015 00:15:15 +0200, "R.Wieser" <add...@not.available>
wrote:

>And copy one of those "examples" when they have been posted as having a
>problem themselves ? Not bloody likely.

He did. Almost verbatim, except for moving the error checks around and
some clueless guessing about libraries and headers he thought he
needed.

[snip hostile retorts and other nonsense]

[Geoff]

On Thu, 09 Apr 2015 15:33:10 -0700, Geoff <ge...@invalid.invalid>
wrote:

>On Fri, 10 Apr 2015 00:15:15 +0200, "R.Wieser" <add...@not.available>
>wrote:
>
>>And copy one of those "examples" when they have been posted as having a
>>problem themselves ? Not bloody likely.
>
>He did. Almost verbatim, except for moving the error checks around and
>some clueless guessing about libraries and headers he thought he
>needed.
>

Even to the point of copying the exact same bad C:\test.txt\ path and
the extra spaces in "file contents here" in the hdrs array.

In 2009:
http://stackoverflow.com/questions/1985345/dev-c-wininet-upload-file-using-http

In 2014:
http://stackoverflow.com/questions/22400079/wininet-upload-file-tchar-problems

[Geoff]

On Fri, 10 Apr 2015 00:15:15 +0200, "R.Wieser" <add...@not.available>
wrote:

>> Yes, our discussion is over. Again.
>
>Yes, we had one. Upto a point. Or at least, I thought we had. After that
>... not so much.

Because every time I tried to explain my thought process at the time I
posted my recommendation you saw fit to disparage and berate the
offered explanation. I'm not the one who initiated this discussion. I
never asked you to reply to my original post but you saw fit to do so.
I would have preferred to have never entered into it. Your tone to
everyone who posts in this group is hostile, arrogant and
condescending.

[Geoff]

On Fri, 10 Apr 2015 00:15:15 +0200, "R.Wieser" <add...@not.available>
wrote:

>And me being "brilliant and insightful" ? Most likely its just experience
>speaking, having a few decades of it.
>

Yes, brilliant and insightful and you had to correct your own first
post in this topic within hours of telling Azeem to look at the script
output.

[Geoff]

If anyone cares anymore, here is a corrected and simplified version
that compiles and runs without errors and reports additional details
in the event of a socket error. I tried to reformat everything to 80
character boundary but beware line-wraps.

#include <windows.h>
#include <wininet.h>
#include <tchar.h>
#include <iostream>

#pragma comment(lib, "Wininet.lib")

/* This example creates a text.txt file on a web server with
* the content specified in the form data.
* This example may provide a starting point for writing one
* that may transmit an arbitrary file from client to server.
* Compiles and functions correctly even when UNICODE is
* defined.
*/

int main()
{

CHAR hdrs[] =
("Content-Type: multipart/form-data; "
"boundary=---------------------------7d82751e2bc0858");
CHAR frmdata[] =
("-----------------------------7d82751e2bc0858\r\n"
"Content-Disposition: form-data; name=\"uploadedfile\"; "
"filename=\"test.txt\"\r\n"
"Content-Type: text/plain\r\n"
"\r\nThis is the content of the text file.\r\n"
"-----------------------------7d82751e2bc0858--\r\n");
LPCSTR accept[] = {("*/*"), NULL};

//Use the *A functions because HTTP requires it.
HINTERNET hSession = InternetOpenA(("MyAgent"),
INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0);
HINTERNET hConnect = InternetConnectA(hSession, ("localhost"),
INTERNET_DEFAULT_HTTP_PORT, NULL, NULL,
INTERNET_SERVICE_HTTP, 0, 1);
HINTERNET hRequest = HttpOpenRequestA(hConnect, ("POST"),
("cgi-bin/uploadfile.php"), NULL, NULL, accept, 0, 1);
BOOL sent = HttpSendRequestA(hRequest, hdrs, strlen(hdrs),
frmdata, strlen(frmdata));

if(hSession == NULL)
{
std::cout << "Error: InternetOpen" << std::endl;
}
else if(hConnect == NULL)
{
std::cout << "Error: InternetConnect" << std::endl;
}
else if(hRequest == NULL)
{
std::cout << "Error: HttpOpenRequest" << std::endl;
}
else if(!sent)
{
std::cout << "Error: HttpSendRequest" << std::endl;
}

if (DWORD error = GetLastError())
std::cout << "Error returned was " << error << std::endl;

DWORD status;
DWORD statusLength = sizeof(status);
HttpQueryInfo(hRequest,
HTTP_QUERY_STATUS_CODE | HTTP_QUERY_FLAG_NUMBER,
&status, &statusLength, nullptr);
if (status != 200)
std::cout << "HTTP status: " << status << std::endl;

//close any valid internet-handles
InternetCloseHandle(hSession);
InternetCloseHandle(hConnect);
InternetCloseHandle(hRequest);
return 0;
}


/*
This is the server side script. It accepts form data and
puts it in the given named file. The uploads folder must
already exist.

<?php

$uploaddir = '../uploads/';
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);

echo "<p>";

if (move_uploaded_file($_FILES['userfile']['tmp_name'],

$uploadfile)) {
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "Upload failed";
}

echo "</p>";
echo '<pre>';

echo "request headers: ";
print_r(apache_request_headers());

echo 'Here is some more debugging info:';
print_r($_FILES);
print "</pre>";

?>

*/

[R.Wieser]

Geoff,

> Even to the point of copying the exact same bad C:\test.txt\
> path

Leave the "even to the point" outof it, and I (somewhat) agree with you
(you're overbearing again). That data is the same. The code is only
similar (which would be, as I already mentioned, hard not to with just three
functons), but definitily not the same.

> and the extra spaces in "file contents here" in the hdrs array.

You made a mistake there: the 2014 thread doesn't contain that phrase.
Also, that one includes the solution to the problem.

So, the OPs code has got the *exact same* data as the 2009 version.

But than the odd thing: both are posted as *problems*. I do not think that
*anyone* would try to start a new project starting with clearly mentioned
non-performing code. Do you ?

When I did look at the 2009 thread I noticed the name "student" (also in his
download URL). Maybe the whole "secret" of this is that the data and
to-be-used functions are simply coming from a teaching assignment ?

As for the "some clueless guessing", hows that different from your stance
that the OP *must* have had an error, as well as you fumbling around with
that debugger, not even knowing what you are actually looking for ?

In other words: if you want bicker like that, be at least reasonable sure
that you're not guilty of the same.

As for me ? I see someone who most likely tried stuff himself before asking
for help. I would be inclined to applaude him for his efforts instead of
trying to push him down.


But again, how is any of the above relevant to the OPs problem ?

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

qj0eia9hul6g5ginc...@4ax.com...

[R.Wieser]

Geoff,

> Because every time I tried to explain my thought process
> at the time I posted my recommendation you saw fit to
> disparage and berate the offered explanation.

From my POV I've had to deal with someone who proposed a "solution" that was
anthing but, but who nonetheless kept defending it, did not even acknowledge
my proposed method as a viable one and kept pressing his own, even though he
had no idea what he was looking for and therefore with that method could
have easily missed it. And every f*cking time I tried to mention anything
along those lines I was ignored.

> I never asked you to reply to my original post but you saw fit to do so.

Yeah, thats definitily odd. It seems to often happen when someone makes a
bogus claim when there are a lot of people around listening in. I wonder
why ...

As for replying to *you* ? You wheren't my target, the OP was. You
where, at best, by-catch. But yes, that preamble was there as an attempt to
curtail your arrogance, the resulting nonsense "help" and negative attitude
towards the OP.

> Your tone to everyone who posts in this group is hostile,
> arrogant and condescending.

Lol. Try again.

I however have *very* little patience for anyone who tries to convince me
that they are right because ... well, they are sure they are. Most likely
you are misinterpreting my straightforwardness in not taking (such)
bullcrap.

Also, your own description fits you. Yes, including that hostility. I'm
just a bit more honest/crude in showing my displeasure than you I'm afraid.

You are one of those people who will try to, as I already mentioned, twist
and bend someones words and what has happened so it will seemingly prooving
you right, and the other wrong. Luckily, you basically stink at it (or
maybe I'm just better than the people you normally encounter at detecting
such attempts :-) )

How's that for brutally honest ?

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

nu0eiapc7uskok2jg...@4ax.com...

[R.Wieser]

Geoff,

> If anyone cares anymore, here is a corrected and simplified version

No, you didn't *correct* nor simplify it. All you did is to *evade* the
problem by going ANSI only.

All you really needed to do was to, in the OPs posted code, change the TCHAR
for the "frmdata" string to "char", and the code would most likely compile,
run and emit the right output in both wide-char and ANSI mode projects.

Also, you have "solved" one problem, but created another.

Like what would needed to be done, when this code would be dropped into a
(default!) wide-character -mode project, to add some extra dynamic info to
the headers of this request. Same for when someone would decide to try to
make, for instance, the "localhost" parameter variable.


Oh ... Was I again expected *not* to respond to it, even though you dropped
it into a room where everybody is listening to everyone ? I'm sorry ....

Regards,
Rudy Wieser


-- Origional message.

Geoff <ge...@invalid.invalid> schreef in berichtnieuws

592eiadq9kci5sa93...@4ax.com...

> file://Use the *A functions because HTTP requires it.

> file://close any valid internet-handles

[R.Wieser]

Geoff,

> He did. Almost verbatim,

I already responded to that too. Multiple times now.

But now you mention it, hows that for "and start a completely irrelevant
discussion" (to the problem at hand) ?

And what does it actually *matter* if he did or not ?

Regards,
Rudy Wieser

Geoff <ge...@invalid.invalid> schreef in berichtnieuws

4cvdia59qtb724a6t...@4ax.com...

[R.Wieser]

Geoff,

> Yes, brilliant and insightful and you had to correct your own
> first post in this topic within hours of telling Azeem to look at
> the script output.

So many mistakes in so little ...

*You* where the one using that "brilliant and insightful" description, not
me. I even downplayed it, throwing it onto my experience.

Yes, I felt I had the duty to correct my own post, as it really did contain
a mistake. Not about the problem-solving method itself (as you again try to
make it sound), but a minor one, about how to look at the received data (I
tried both methods, and simply mixed them up)

I could have choosen to keep silent about it hoping nobody would spot it,
maybe even assuming Azeem would be smart enough to look the used command up
on w3schools.com or something like it, but I didn't.

When was the last time you had the guts to tell anyone that you made a
mistake ?

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

ne1eiatk3bc8p2tvi...@4ax.com...

[Richard Heathfield]

On 10/04/15 10:40, R.Wieser wrote:

<snip>

> When was the last time you had the guts to tell anyone that you made a
> mistake ?

Yesterday, I think.

I'm not so sure that it takes courage to admit to a mistake (despite the
fact that certain kinds of Net warrior tend to leap on it as an
admission of incompetence, whereas in fact it is nothing of the kind).
It's just plain common sense. The wiser among one's correspondents will
accept the admission for what it is, and will also recognise that one
has not fallen victim to the "I'm perfect" fallacy.

That's not to say that one should admit to /every/ mistake. I am not
accustomed to falling prey to typographical errors in my articles, but
it does happen occasionally. If I apologised for all of them, even when
the meaning is obvious from context, I think my personal SNR would drop
dramatically.

Nevertheless, there are times when one has made such a glaring error
that one cannot avoid admitting to it. For example, it is a mistake for
two people who clearly know so much about Windows programming to get
themselves involved in a pointless slanging match which does neither of
them any credit.

Time, gentlemen, please!

[R.Wieser]

Richard,

> Yesterday, I think.

:-) I was aiming that at Geoff, but thanks for responding nonetheless. What
you say there is pretty-much the same as I'm think about it.

We're all human. There is, or rather *should* be no shame in admitting to a
mistake when we make one. And as someone once said, its not about the
mistake itself (within limits ofcourse!), but how you deal with it.

> Nevertheless, there are times when one has made such a glaring error
> that one cannot avoid admitting to it. For example, it is a mistake for
> two people who clearly know so much about Windows programming to get
> themselves involved in a pointless slanging match which does neither of
> them any credit.

I know, I really should just have stopped responding. I even activily tried
...

I also think I was quite friendly in my posts, but at the same time clear
about not accepting crap. Ofcourse, I'm saying that standing smack in the
middle of the forrest, seeing only trees. :-)

> Time, gentlemen, please!

You're right. Its much better when this ends.

Regards,
Rudy Wieser


-- Origional message:

Richard Heathfield <r...@cpax.org.uk> schreef in berichtnieuws
mg8ai8$cj5$1...@dont-email.me...

[Geoff]

On Fri, 10 Apr 2015 12:19:25 +0200, "R.Wieser" <add...@not.available>
wrote:

>All you really needed to do was to, in the OPs posted code, change the TCHAR
>for the "frmdata" string to "char", and the code would most likely compile,
>run and emit the right output in both wide-char and ANSI mode projects.

I considered that. My initial change was to change hdrs and frmdata to
CHAR and HttpSendRequest to HttpSendRequestA.

The only function that misbehaves is the HttpSendRequest. All the
preceding ones convert their WCHARS to CHARS before transmitting them.
You ultimately have to either write it using HttpSendRequestA or let
the compiler fail on the parameter conversion error. It seemed to me
this error is what set off all the problems and tweaks in the posted
code in the first place. I decided to emphasize the necessity of the
ANSI strings over allowing Unicode to leak onto the network side.