TCPClient in HTTp Request

[jin]

hi, i'm trying using the tcpClient to get a html file from net, instead of
using WebClient or WebRequest,

the main part of the source code is like this:

private void tcpconnect()
{
tcp=new TcpClient("www. yahoo.com",80);
tcp.NoDelay=fal se;
tcp.ReceiveTime out=60000;
tcp.ReceiveBuff erSize=25000;
stream = tcp.GetStream() ;
byte[] send = Encoding.ASCII. GetBytes("GET /index.html HTTP/1.0\r\n\r\n");
stream.Write(se nd,0,send.Lengt h);

byte[] receive = new byte[tcp.ReceiveBuff erSize];

int lastreceive=str eam.Read(receiv e,0,tcp.Receive BufferSize);
string str = Encoding.ASCII. GetString(recei ve,0,tcp.Receiv eBufferSize);

textBox1.Text=s tr;
tcp.Close();
stream.Close();
}

but the problem is, while i try to run this function, it didn't read all the
html source code for me, but just a part, i try to run twice of the read
method in the function, and it does continue reading for me. I think there
might be some other function which allow us to check whether the html file is
finished loading or not, but i'm dunno which is it and i can't find it
through the msdn library. Is that anyone could help?

Thank for all

[Cool Guy]

Wessel Troost <no*****@like.t he.sun> wrote:

int lastreceive=str eam.Read(receiv e,0,tcp.Receive BufferSize);
string str =
Encoding.ASCII. GetString(recei ve,0,tcp.Receiv eBufferSize);

Call these functions recursively until stream.Read() returns 0 to indicate
end-of-stream.

But an HTTP/1.1 server might *not* close the connection after sending the
response.

The OP should read the HTTP/1.1 RFC if he wants to implement an HTTP client
at this time.

[Wessel Troost]

> But an HTTP/1.1 server might *not* close the connection after sending the

response.
You can specify the HTTP version in your request, which would eliminate
this speculative problem?
The OP should read the HTTP/1.1 RFC if he wants to implement an HTTP
client
at this time.

To write a generic client, the OP might have to read the specification.
On the other hand, he might just want to contact a specific server, with a
specific IIS or Apache version, which behaves consistently. In which case
reading the RFC would be like shooting a mouse with a nuclear bomb.

Not that anyone could read an RFC and come up with correct code. It takes
groups of developers years to do that.

Greetings,
Wessel

[Chad Z. Hower aka Kudzu]

"Wessel Troost" <no*****@like.t he.sun> wrote in
news:op.st9mdvq rf3yrl7@asbel:

You can specify the HTTP version in your request, which would
eliminate this speculative problem?
Only that one. It wont help you with URL encoding, Chunked transfers, or many of the other things
in HTTP 1.0.
To write a generic client, the OP might have to read the
specification. On the other hand, he might just want to contact a
specific server, with a specific IIS or Apache version, which behaves
consistently. In which case reading the RFC would be like shooting a
mouse with a nuclear bomb.
No - you've seriously understimated the task and do not understand HTTP nor the RFC's. The RFC
is the consistency. IIS and Apache both conform to it. Various user configurations, proxies and
document types will alter your "observed consistency of a single test URL".

Just because you run one test - does not meant it will always respond in that manner.
Not that anyone could read an RFC and come up with correct code. It
takes groups of developers years to do that.

Which is why you should use an ready made HTTP client and not write one unless you intend to do
it correctly. I can teach my wife how to write a Hello World - but saying "Well its consistent" and
she doesnt need the rest does not mean I can take a vacation and give her my job.

HTTP looks deceptively simple - and small test programs will work in the SHORT TERM.
However there are many more complexities to HTTP than first appear and such hacks will not
work long term.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/

[Chad Z. Hower aka Kudzu]

"Wessel Troost" <no*****@like.t he.sun> wrote in
news:op.st9mdvq rf3yrl7@asbel:

You can specify the HTTP version in your request, which would
eliminate this speculative problem?
Only that one. It wont help you with URL encoding, Chunked transfers, or many of the other things
in HTTP 1.0.
To write a generic client, the OP might have to read the
specification. On the other hand, he might just want to contact a
specific server, with a specific IIS or Apache version, which behaves
consistently. In which case reading the RFC would be like shooting a
mouse with a nuclear bomb.
No - you've seriously understimated the task and do not understand HTTP nor the RFC's. The RFC
is the consistency. IIS and Apache both conform to it. Various user configurations, proxies and
document types will alter your "observed consistency of a single test URL".

Just because you run one test - does not meant it will always respond in that manner.
Not that anyone could read an RFC and come up with correct code. It
takes groups of developers years to do that.

Which is why you should use an ready made HTTP client and not write one unless you intend to do
it correctly. I can teach my wife how to write a Hello World - but saying "Well its consistent" and
she doesnt need the rest does not mean I can take a vacation and give her my job.

HTTP looks deceptively simple - and small test programs will work in the SHORT TERM.
However there are many more complexities to HTTP than first appear and such hacks will not
work long term.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/

[Cool Guy]

Wessel Troost <no*****@like.t he.sun> wrote:

But an HTTP/1.1 server might *not* close the connection after sending the
response.

You can specify the HTTP version in your request, which would eliminate
this speculative problem?

Of course. My mistake.

[Cool Guy]

Wessel Troost <no*****@like.t he.sun> wrote:

But an HTTP/1.1 server might *not* close the connection after sending the
response.

You can specify the HTTP version in your request, which would eliminate
this speculative problem?

Of course. My mistake.