HTTPWebRequest - IO.Streamwriter and Mysterious Line Feed

[=?Utf-8?B?UGF1bA==?=]

I am using HTTPWebRequest to programatically send a HTTP POST request.

I have a long string (400 characters): dim str as string = "xxxxx...."

It is a value that is passed in the HTTP Post header.

So I do something like this:

Request = HttpWebRequest.Create(URL)
Request.Type = "POST"
IOWriter = New IO.StreamWriter(Request.GetRequestStream())
IOWriter.Write(PostData)
dim Request As HttpWebRequest = Request.GetResponse()

The request is sent properly but for some reason, a LINE FEED IS INSERTED
INTO THE STR VARIABLE AFTER 80 CHARACTERS?

This is bizarre.

Has anyone come across something like this?

I believe it must have something to do with the IO.Streamwriter but it
really makes no sense.

Can anyone help?

TIA

[Andy]

How do you know a LF/CR is being inserted into your str variable? Are
you actually looking inside str, or are you assuming this from what
was posted?

If you are seeing LF/CR in str, then you should look at how you are
populating the variable. If you are reading from a file, is the read
routine assuming a line length of 80 and returning a LF/CR because you
are using a read command designed to read input lines?

It seems unlikely that the writer/streamwriter is modifying your input
when it writes out.

If you are seeing this in your posted output, then are you using
something like .writeline that automatically appends CR/LF?

If you are posting to another system (such as UNIX based) through a
gateway, then check if the gateway is doing any character conversion
that maybe responsible for the LF/CR.

[=?Utf-8?B?UGF1bA==?=]

Yes, this was my first thought. But I am pretty certain that the CR/LF is not
in the string variable when the Streamwriter is sent.

I use VS2005 and I do a watch on that variable and I do not see any CR/LF in
there.

The only way that I know it is there is I have a HTTP monitoring program and
I can see that when the request is sent, there are linefeeds in the HTTP
header associated with that variable.

Very wierd.

"Andy" wrote:

How do you know a LF/CR is being inserted into your str variable? Are
you actually looking inside str, or are you assuming this from what
was posted?

If you are seeing LF/CR in str, then you should look at how you are
populating the variable. If you are reading from a file, is the read
routine assuming a line length of 80 and returning a LF/CR because you
are using a read command designed to read input lines?

It seems unlikely that the writer/streamwriter is modifying your input
when it writes out.

If you are seeing this in your posted output, then are you using
something like .writeline that automatically appends CR/LF?

If you are posting to another system (such as UNIX based) through a
gateway, then check if the gateway is doing any character conversion
that maybe responsible for the LF/CR.

[=?Utf-8?B?UGF1bA==?=]

Ok, I have found the problem but still need help with the solution.

The large string that I was referring to has character sequences like "%0A"
(which is a hex code for a line feed).

So when I send that string in a HTTPWebRequest, the code converts that into
a linefeed.

Essentially, it automatically encodes it when I do not want it encoded.

I know about server.urlencode, etc. Is that where I would find a solution?
"Andy" wrote:

How do you know a LF/CR is being inserted into your str variable? Are
you actually looking inside str, or are you assuming this from what
was posted?

If you are seeing LF/CR in str, then you should look at how you are
populating the variable. If you are reading from a file, is the read
routine assuming a line length of 80 and returning a LF/CR because you
are using a read command designed to read input lines?

It seems unlikely that the writer/streamwriter is modifying your input
when it writes out.

If you are seeing this in your posted output, then are you using
something like .writeline that automatically appends CR/LF?

If you are posting to another system (such as UNIX based) through a
gateway, then check if the gateway is doing any character conversion
that maybe responsible for the LF/CR.