[OT] .NET Rant

C

C# Learner

I've been learning .NET for a couple of weeks now.

I've found that on the surface, .NET looks powerful and very handy.
However, when getting down and dirty with it, I've found that
sometimes it's no longer the beast it first appeared. It then shows
itself to be irrationally impotent in certain aspects.

Here are a couple of examples:

Example 1
---------

An HttpWebRequest instance cannot be given a "raw" HTTP message. I
see absolutely no reason why this is so, since somewhere along the
line of an HttpWebRequest instance sending a HTTP request, a raw HTTP
message will be sent.

Instead, if one has a raw HTTP message in the first place, one must
parse the raw message (whether it be held in string, byte[], etc.)
into an HttpWebRequest instance.

Why should the user of .NET have to do this? This is ridiculous. In
this case extra processing is involved:

1) User code parses raw HTTP message and builds a new HttpWebRequest
instance from it.
2) HttpWebRequest code then does the complete opposite to get a raw
HTTP message.
3) HttpWebRequest then sends raw HTTP message.

Instead, the following should happen:

1) HttpWebRequest has the ability to send a raw HTTP message, given to
it by user.

Example 2
---------

One cannot retrieve the "raw" HTTP message from an HttpWebResponse.
Again, I see no reason why this should be so, since somewhere along
the line of getting an HTTP response a raw HTTP message is received.

Instead, one must do something like the following:

byte[] headerBytes = response.Headers.ToByteArray();

Then one must somehow prepend the string "HTTP 200 OK\r\n" to those
bytes. Next, of course, one must append the response body.

An example of the clumsiness involved:

string statusString = "HTTP/1.1 200 OK\r\n";
byte[] statusBytes = Encoding.ASCII.GetBytes(statusString);
byte[] headerBytes = response.Headers.ToByteArray();
byte[] bodyBytes = ReadFully(response.GetResponseStream());

// ReadFully is implemented as (obtained from Jon Skeet's site):
public static byte[] ReadFully(Stream stream)
{
byte[] buffer = new byte[32768];
using (MemoryStream ms = new MemoryStream())
{
while (true)
{
int read = stream.Read(buffer, 0,
buffer.Length);
if (read <= 0)
return ms.ToArray();
ms.Write(buffer, 0, read);
}
}
}

Here, we have obtained three byte arrays which add up to a full HTTP
message.

Why can't we simply say the following?

byte[] messageBytes = response.GetRawMessage();

That would be so much nicer, and would be easy to implement. Perhaps
even the following might be more logical:

byte[] messageBytes = response.RawMessage;

....depending on whether an HttpResponse stores the raw message using a
byte[] instance.

Further, why should I need to read from one stream, write to another,
and then, finally, convert this stream to a byte array?

That is bound to be rather inefficient, not to mention the fact that
it takes the implementation of a whole new method.
 
G

gabriel

C# Learner said:
sometimes it's no longer the beast it first appeared. It then shows
itself to be irrationally impotent in certain aspects.

That's fine, but I don't think .NET was built to address what you are
doing optimally.

First of all, after doing many web apps, I have never needed to use the
"raw" stuff you are trying to do.

Second of all, you are breaking the abstraction layer by doing what you
are trying to do.

If you want to bypass the abstraction layer, you are better off playing
with sockets, rather than HTTP objects.

Anyway, to me .NET does what I need, when I have an app with different
requirements, I use a more appropriate language and platform.

If you are complaining that .NET is not the best for every possible task,
you are right, it is not. That's when you should go off and use the
right tool for the task.
 
C

C# Learner

gabriel said:
That's fine, but I don't think .NET was built to address what you are
doing optimally.

First of all, after doing many web apps, I have never needed to use the
"raw" stuff you are trying to do.

Second of all, you are breaking the abstraction layer by doing what you
are trying to do.

If you want to bypass the abstraction layer, you are better off playing
with sockets, rather than HTTP objects.

The thing is, HttpWebRequest and HttpWebResponse would be *ideal* for
what I want to do. Since they don't have this fundamental
functionality, I'm going to have to reinvent the wheel.

I will now have to go and make two classes, called HttpRequest and
HttpResponse, which act exactly like the above two, except that they
allow "raw" packet access. In this case, .NET is nowhere near ideal
for the lazy programmer, as has been claimed many a time.
Anyway, to me .NET does what I need, when I have an app with different
requirements, I use a more appropriate language and platform.

If you are complaining that .NET is not the best for every possible task,
you are right, it is not. That's when you should go off and use the
right tool for the task.

Why do MS tout it as the be-all and end-all then? I see now that this
is *false* advertising.
 
G

gabriel

C# Learner said:
The thing is, HttpWebRequest and HttpWebResponse would be *ideal* for
what I want to do. Since they don't have this fundamental
functionality, I'm going to have to reinvent the wheel.

Obviously, if you have to reinvent the wheel, the built in classes are
_not_ ideal...
I will now have to go and make two classes, called HttpRequest and
HttpResponse, which act exactly like the above two, except that they
allow "raw" packet access. In this case, .NET is nowhere near ideal
for the lazy programmer, as has been claimed many a time.

The lazy programmer would use what is built in. Again, in normal
programming I have never had to go beyond the built in stuff, specially
look at the raw data from HTTP requests.
Why do MS tout it as the be-all and end-all then? I see now that this
is *false* advertising.

I don't think they do. There's certainly a ton of stuff you cannot do
with it, even at first glance (ie, write an O/S boot loader, write an
effective memory manager, etc...) and there's stuff that would take
longer if you tried to do it in .NET than in another language (ie, a disk
secotr editor, low-level o/s intensive stuff, etc...)

Anyway, I better shut up before the "since I only know how to use a
hammer, everything looks like a nail" .NET-only gang.
 
C

C# Learner

I don't think they do. There's certainly a ton of stuff you cannot do
with it, even at first glance (ie, write an O/S boot loader, write an
effective memory manager, etc...) and there's stuff that would take
longer if you tried to do it in .NET than in another language (ie, a disk
secotr editor, low-level o/s intensive stuff, etc...)

Well, I meant the be-all and end-all for application-level
programming. And this is the impression I have got from MS articles.
Anyway, I better shut up before the "since I only know how to use a
hammer, everything looks like a nail" .NET-only gang.

Huh?
 
J

Jon Skeet [C# MVP]

C# Learner said:
I've been learning .NET for a couple of weeks now.

I've found that on the surface, .NET looks powerful and very handy.
However, when getting down and dirty with it, I've found that
sometimes it's no longer the beast it first appeared. It then shows
itself to be irrationally impotent in certain aspects.

Here are a couple of examples:

Example 1
---------

An HttpWebRequest instance cannot be given a "raw" HTTP message. I
see absolutely no reason why this is so, since somewhere along the
line of an HttpWebRequest instance sending a HTTP request, a raw HTTP
message will be sent.

Instead, if one has a raw HTTP message in the first place, one must
parse the raw message (whether it be held in string, byte[], etc.)
into an HttpWebRequest instance.

If you've got the raw request, why bother with HttpWebRequest at all?
Why not just make the socket connection and send it yourself? That also
answers your problem about getting the raw response. I fail to see what
value you're really wanting HttpWebRequest/Response to add in this
situation.
 
G

gabriel

C# Learner said:

Of the .NEt apologists that lurk around, some are really religious about
not putting down .NET under any circumstances, so they attack as soon as
someone starts saying that there might be a better way than the .NET way to
accomplish a task.
 
C

C# Learner

gabriel said:
Of the .NEt apologists that lurk around, some are really religious about
not putting down .NET under any circumstances, so they attack as soon as
someone starts saying that there might be a better way than the .NET way to
accomplish a task.

Ah, I see. :)
 
C

C# Learner

Jon Skeet said:
If you've got the raw request, why bother with HttpWebRequest at all?
Why not just make the socket connection and send it yourself? That also
answers your problem about getting the raw response. I fail to see what
value you're really wanting HttpWebRequest/Response to add in this
situation.

Well, the app I'm making here is a basic HTTP proxy server. Using
HttpWebRequest and HttpWebResponse would be excellent for me, since
they take care of almost anything already.

Implementing the proxy with, say, TcpClient instances would take a
whole lot of extra work. The biggest annoyance about this would be
writing the code that knows when the response from the remote server
has finished (checking content-length, or calculating differently if
the response is "chunked", etc.), so as not to hang on the next "Read"
call, etc.

It's something that could so easily be avoided if these two classes
had this fundamental functionality.
 
C

Chad Z. Hower aka Kudzu

C# Learner said:
Well, the app I'm making here is a basic HTTP proxy server. Using
HttpWebRequest and HttpWebResponse would be excellent for me, since
they take care of almost anything already.

Or just use HTTP in Indy - It has full HTTP support (Even more than what
comes with .net) and allows you to do raw posts rather easily.

http://www.indyproject.org/indy.html


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
J

Jon Skeet [C# MVP]

C# Learner said:
Well, the app I'm making here is a basic HTTP proxy server. Using
HttpWebRequest and HttpWebResponse would be excellent for me, since
they take care of almost anything already.

But if you want to specify the whole request and response yourself,
what *would* they actually take care of for you?
Implementing the proxy with, say, TcpClient instances would take a
whole lot of extra work.

Why, if you've already constructed the exact request you want to send,
and you want the exact response back?
The biggest annoyance about this would be
writing the code that knows when the response from the remote server
has finished (checking content-length, or calculating differently if
the response is "chunked", etc.), so as not to hang on the next "Read"
call, etc.

It's something that could so easily be avoided if these two classes
had this fundamental functionality.

Hmmm... possibly, although in my experience mixing "raw" access and
access via properties etc can often result in problems with the two
models getting out of sync. It's possible, but often ugly.
 
C

C# Learner

Jon Skeet said:
But if you want to specify the whole request and response yourself,
what *would* they actually take care of for you?

As I say, the biggest thing they'd take care of is getting the whole
response from the remote server. This isn't entirely /simple/, as
I've seen in the past, and it takes a fair amount of deciding code.

This code is already provided in these classes. However, due to the
restriction I'm ranting about, the classes are inept for use in an
HTTP proxy.
Why, if you've already constructed the exact request you want to send,
and you want the exact response back?

You're right - I do already construct the request by reading it from
the web browser that's using the proxy. However, since this is a
proxy, I need to be able to send this request to the appropriate
server and then get the exact response from the server, and send it
back to the web browser.
Hmmm... possibly, although in my experience mixing "raw" access and
access via properties etc can often result in problems with the two
models getting out of sync. It's possible, but often ugly.

Understandable, I guess.

Cheers Jon.
 
P

Pete Davis

First of all, I think saying the whole platform is bad because it doesn't do
some very specific, unusual thing that you want it to do is a bit petty.
Sorry, but that's like saying .NET sucks because it doesn't let me access
the raw sectors of a disk from the StreamReader.

HttpWebRequest and HttpWebResponse are a layer of abstraction to get you
away from the raw sockets. But, the raw sockets are there if HttpWebRequest
and HttpWebResponse don't do what you need.

Someone else mentioned Indy.

No language or platform will ever meet every single person's individual
quirky needs. That's why people write libraries like Indy.

If .NET had everything, then people would complain that it's too bloated and
too big/complex to learn. Somewhere you have to draw the line.

Pete

--
http://www.petedavis.net

C# Learner said:
I've been learning .NET for a couple of weeks now.

I've found that on the surface, .NET looks powerful and very handy.
However, when getting down and dirty with it, I've found that
sometimes it's no longer the beast it first appeared. It then shows
itself to be irrationally impotent in certain aspects.

Here are a couple of examples:

Example 1
---------

An HttpWebRequest instance cannot be given a "raw" HTTP message. I
see absolutely no reason why this is so, since somewhere along the
line of an HttpWebRequest instance sending a HTTP request, a raw HTTP
message will be sent.

Instead, if one has a raw HTTP message in the first place, one must
parse the raw message (whether it be held in string, byte[], etc.)
into an HttpWebRequest instance.

Why should the user of .NET have to do this? This is ridiculous. In
this case extra processing is involved:

1) User code parses raw HTTP message and builds a new HttpWebRequest
instance from it.
2) HttpWebRequest code then does the complete opposite to get a raw
HTTP message.
3) HttpWebRequest then sends raw HTTP message.

Instead, the following should happen:

1) HttpWebRequest has the ability to send a raw HTTP message, given to
it by user.

Example 2
---------

One cannot retrieve the "raw" HTTP message from an HttpWebResponse.
Again, I see no reason why this should be so, since somewhere along
the line of getting an HTTP response a raw HTTP message is received.

Instead, one must do something like the following:

byte[] headerBytes = response.Headers.ToByteArray();

Then one must somehow prepend the string "HTTP 200 OK\r\n" to those
bytes. Next, of course, one must append the response body.

An example of the clumsiness involved:

string statusString = "HTTP/1.1 200 OK\r\n";
byte[] statusBytes = Encoding.ASCII.GetBytes(statusString);
byte[] headerBytes = response.Headers.ToByteArray();
byte[] bodyBytes = ReadFully(response.GetResponseStream());

// ReadFully is implemented as (obtained from Jon Skeet's site):
public static byte[] ReadFully(Stream stream)
{
byte[] buffer = new byte[32768];
using (MemoryStream ms = new MemoryStream())
{
while (true)
{
int read = stream.Read(buffer, 0,
buffer.Length);
if (read <= 0)
return ms.ToArray();
ms.Write(buffer, 0, read);
}
}
}

Here, we have obtained three byte arrays which add up to a full HTTP
message.

Why can't we simply say the following?

byte[] messageBytes = response.GetRawMessage();

That would be so much nicer, and would be easy to implement. Perhaps
even the following might be more logical:

byte[] messageBytes = response.RawMessage;

...depending on whether an HttpResponse stores the raw message using a
byte[] instance.

Further, why should I need to read from one stream, write to another,
and then, finally, convert this stream to a byte array?

That is bound to be rather inefficient, not to mention the fact that
it takes the implementation of a whole new method.
 
C

C# Learner

Pete Davis said:
First of all, I think saying the whole platform is bad because it doesn't do
some very specific, unusual thing that you want it to do is a bit petty.
Sorry, but that's like saying .NET sucks because it doesn't let me access
the raw sectors of a disk from the StreamReader.

HttpWebRequest and HttpWebResponse are a layer of abstraction to get you
away from the raw sockets. But, the raw sockets are there if HttpWebRequest
and HttpWebResponse don't do what you need.

Someone else mentioned Indy.

No language or platform will ever meet every single person's individual
quirky needs. That's why people write libraries like Indy.

If .NET had everything, then people would complain that it's too bloated and
too big/complex to learn. Somewhere you have to draw the line.

I'm not asking for .NET to have everything. I'm simply ranting about
how in this case, .NET let me down big time where it didn't really
need to. I'm not asking for a whole load of functionality to added.
I'm simply implying that not allowing access to the raw packets was a
bad idea.
 
C

C# Learner

C# Learner said:
I'm not asking for .NET to have everything. I'm simply ranting about
how in this case, .NET let me down big time where it didn't really
need to. I'm not asking for a whole load of functionality to added.
I'm simply implying that not allowing access to the raw packets was a
bad idea.

The raw HTML message, I mean.
 
P

Pete Davis

Regardless, my comment stands. It's a layer of abstraction. The point of a
layer of abstraction is to "HIDE" the details that, in this case, probably
covers about 95+% of peoples needs.

It's a very small issue and your initial post made it sound like the entire
framework is defective because it doesn't support your particular need.

Pete
 
F

FDude

C# Learner said:
I've been learning .NET for a couple of weeks now.

I've found that on the surface, .NET looks powerful and very handy.
However, when getting down and dirty with it, I've found that
sometimes it's no longer the beast it first appeared. It then shows
itself to be irrationally impotent in certain aspects.

If you thought that the .NET framework was the "be all and end all of
application programming" (as you stated in other posts), why do you think MS
is releasing .NET 2.0 if 1.1 already does everything?
 
C

C# Learner

FDude said:
If you thought that the .NET framework was the "be all and end all of
application programming" (as you stated in other posts), why do you think MS
is releasing .NET 2.0 if 1.1 already does everything?

As I stated in the other post, that's my impression of how the .NET
framework is advertised, not what I believe.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top