HttpWebRequest POST not working on my VS2003

[Guest]

Why is .NET leaving out the POST data on my HTTPWebRequest?
I had some code working fine in VS2002 and when I moved to VS2003 it doesn't
seem to be adding the POST data. So I took the same chunk of code and
placed it in VS2005 Beta 1 (on a different machine), and it works there as
well.

When I run the code below in my VS2003 and view the request packet with a
sniffer it is missing th POST content (firstone=Hello World)
Thanks,
Travis
..NET (version 1.1.4322.573)

Imports System.IO
Imports System.Net
Imports System.Text

Module Module1
Sub Main()
System.Net.ServicePointManager.Expect100Continue = False
Dim myReq As HttpWebRequest = _
WebRequest.Create("http://www.contoso.com/codesnippets/next.asp")

Dim postData As String = "firstone" + ChrW(61) + "Hello World"
Dim encoding As New ASCIIEncoding
Dim byte1 As Byte() = encoding.GetBytes(postData)
' Set the content type of the data being posted.
myReq.ContentType = "application/x-www-form-urlencoded"
myReq.Method = "POST"
' Set the content length of the string being posted.
myReq.ContentLength = postData.Length
Dim newStream As Stream = myReq.GetRequestStream()
newStream.Write(byte1, 0, byte1.Length)
newStream.Close()
Dim myResponse As HttpWebResponse = myReq.GetResponse()
End Sub
End Module

 

[Guest]

Update: When I compile the code below on my develpment machine (WinXP) and
run it, it doesn't add the POST data. I take the same compiled EXE file and
run it on another WinXP machine and another Win 2000 machine (both with .NET
version 1.1.4322.573) and the POST data is added.
So I've ruled out problems with the code, or .NET version.
I've compared the GAC for the files on which the EXE is dependent and find
one interesting thing. On machines that run the EXE and add the POST data,
when you view the propeties of files such as system.web and system in the GAC
they have a date for the Modified property and a file name and location for
the Codebase property. My development machine that doesn't add the POST data
has both of those blank.
I've tried uninstalling and re-installing .NET 1.1 and the .NET 1.1 SDK and
get the same thing.
Any Ideas?
Thanks,
Travis

 

[Guest]

First off, I am just learning myself. However, in my research for using
HttpWebRequest most examples, whether in VB or C#, explicitly cast the
result of WebRequest.Create into a HttpWebRequest object

So, in VB, something like:
Dim myReq As HttpWebRequest = _
CType(WebRequest.Create("http://www.contoso.com/codesnippets/next.asp"),
HttpWebRequest)

or C#
HttpWebRequest myReq = (HttpWebRequest)
WebRequest.Create("http://www.contoso.com/codesnippets/next.asp");


Is it not possible that the fact that code works in some versions and not
others could be the result of different versions of the compiler allowing
sloppy type assignment? So, the compiler for which the POST data is
disappearing is strictly enforcing type and the others are not?

The pointer assignment in all cases is legal because in inheritance, a
pointer to a parent object can always be assigned to a child object, but not
vice versa (because the child can contain fields/members the parent does
not). So, the object assignment itself is not causing any errors, but the
non-working version's compiler is only too happy to make the initial object
assignment and then ignore attempts to modify HttpWebRequest properties on
an object the compiler considers to be a pointer to a WebRequest object?


Anyway, that's my shot in the dark, and it is at least easy to test.




your relevant code:

Dim myReq As HttpWebRequest = _

 

[Harold Paine]

Thanks Bill. It was worth a try, but still the same results.
All three computers I've tried it on have the same CLR version, and since
it's the same compiled EXE I'm running, I hope it would be the same.
I'm semi conviced my GAC holds the key to my problem, so I'm going to start
looking there.
Thanks,
-Travis

 

[Guest]

OK, I need help.
The files in my GACs are the same. On two computers when I run the EXE the
POST data gets added to the stream. On my new develpment computer, the POST
data doesn't get added.
Any where else I can look?
Thanks,
Travis

 

[Guest]

I'm starting to think it has something to do with the underlying ServicePoint
that .NET is accessing. I say that because, running the same EXE on two
different computers results in two different request packets. One with the
POST data, and one without. The header on the packet without the POST data
also has a Connection: Keep-Alive.
Spark any ideas in anyone?
Thanks,
Travis

 

[Guest]

I'm still having the same problem, and I was wondering if anybody had any
ideas. The Windows 2000 machine that properly added the post data, began
failing to do so just after a .net framework update on or around the 17th of
April.

 

[Feroze [msft]]

If all you want to do is a Form POST, have you considered a simpler api that
is available - System.Net.WebClient() ?

With two lines of code you can do a Form POST using this class.

Otherwise, looking at your code I see two things:

1) You are using the ASCII encoding to get the byte representation of your
string. This is good. However when you set the content length, you use the
length of the original string, and not the length of the byte array that you
are actually sending.

2) I didnt see you calling WebResponse.CLose(). You need to do this.

--
feroze

-----------------
This posting is provided as-is. It offers no warranties and assigns no
rights.

See http://weblogs.asp.net/feroze_daud for System.Net related posts.
----------------

 

[Joerg Jooss]

If all you want to do is a Form POST, have you considered a simpler
api that is available - System.Net.WebClient() ?

With two lines of code you can do a Form POST using this class.

Otherwise, looking at your code I see two things:

1) You are using the ASCII encoding to get the byte representation of
your string. This is good. However when you set the content length,
you use the length of the original string, and not the length of the
byte array that you are actually sending.

For ASCII, the two sizes are always equal, aren't they? It gets
problematic once you use multibyte encodings like UTF-8 ot -16.

Actually, using ASCII in combination with WebRequest isn't that good,
because it breaks when accessing practically all non-English language
web pages, and it might even break when retrieving English content
(just think of the Euro sign).

Cheers,