Technically, that is a bad request, because you have a space before Host:, but per RFC2616, there should not be any whitespace in a header field name.
Worse: you do not want a space between your /r/n's. Of which two should separate the header from the body ("/r/n/r/n"), not three. That may not seem like such a big issue because there is no body, but you still need an "/r/n/r/n" to indicate the header is complete, and you do not have that. Hence, I think many or most web servers will not respond in kind, and will instead terminate the connection immediately because the request is malformed. That termination takes place via tcp/ip, not http, and if you are doing the wrong thing with the socket (eg, waiting on recv) at the time, it could be fatal to the process.*
How are you are deducing this? Do you mean in the former case "Error with send()" appears? Or nothing? If it is nothing, I would bet that the send did succeed, but the stdout buffer is not flushed before your process recieves a SIGPIPE or SIGHUP while waiting on the recv. Try it with:
Code:
if (send(tcpSocket, request, strlen(request), 0) < 0)
fprintf(stderr, "Error with send()");
else
fprintf(stderr, "Successfully sent html fetch request");
This will avoid buffering issues with stdout if the process has actually died prematurely
while waiting on the recv(). Ie, the the connection was terminated via tcp/ip by the connected server, without sending any http reponse. How servers deal with non-conforming clients is...undefined.
Of course, if you do not wait on the recv(), you will get "Successfully sent html fetch request"; you sent a bad request and so the server (on a tcp/ip level) killed the connection (just as before), but it does not matter because your program already ended (and flushed the stdout buffer on exit).
* you almost certainly want to use a signal handler for SIGPIPE because of that.