Sending compressed Web Service requests to Apache server

[PerryG]

We have a .NET 1.1 client which is sending a gzipped soap request using
HttpWebRequest to an Apache server. The Apache server is using a the
'mod_deflate' server to decompress the incoming message, and to also compress
the response (GZIP).

The mod_deflate filter requires the 'Content-Length' header contained within
the incoming request to specify the number of UNCOMPRESSED bytes being sent
and not the actual bytes of the body of the compressed HTTP request itself.
The problem we have is .NET requires that you specify the number of actual
bytes written to the request stream as specified in the Content-Length header
of the request message. The exception we receive when attempting to close
the stream to send the request is:

[System.IO.IOException]: {System.IO.IOException}
HelpLink: Nothing
InnerException: Nothing
Message: "Cannot close stream until all bytes are written."
Source: "System"
StackTrace: " at System.Net.ConnectStream.CloseInternal(Boolean
internalCall, Boolean ignoreShutDownCheck)"
TargetSite: {System.Reflection.RuntimeMethodInfo}

Is there any way around this issue?

[Steven Cheng[MSFT]]

Hi Perry,

Thanks for your posting. From your description, you're using the
HttpWebREquest component in .net to send a certain compressed package
(GZIP) to a service hosted on a apache web server. That service will
decompress the package and send back a compressed response. The problem is
that that service module need to get the actual length of the uncompressed
package stream rather than the compressed length of the Content-Length in
the httpwebrequest's request message, yes?

As for the HttpWebRequest's ContentLength, i'm afraid this is a fixed
behavior that we must set the value as the actual length of the binary
stream in the Request stream rather than any other value. And this is
defined by the standard http message. Are you sending the compressed
package using the multi-part/form-data contenttype? If so, we can add some
additional name/value fields into the http message body to represent the
uncompressed package's size (or some other custom http headers) , but it
all depend on the serverside's service module which may need to change the
way it retrieve the package's actual size( not use the content-length of
the http message).

Please feel free to post here if you have any other ideas or concerns
Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[PerryG]

"Steven Cheng[MSFT]" wrote:

Hi Perry,

Thanks for your posting. From your description, you're using the
HttpWebREquest component in .net to send a certain compressed package
(GZIP) to a service hosted on a apache web server. That service will
decompress the package and send back a compressed response. The problem is
that that service module need to get the actual length of the uncompressed
package stream rather than the compressed length of the Content-Length in
the httpwebrequest's request message, yes?

As for the HttpWebRequest's ContentLength, i'm afraid this is a fixed
behavior that we must set the value as the actual length of the binary
stream in the Request stream rather than any other value. And this is
defined by the standard http message. Are you sending the compressed
package using the multi-part/form-data contenttype? If so, we can add some
additional name/value fields into the http message body to represent the
uncompressed package's size (or some other custom http headers) , but it
all depend on the serverside's service module which may need to change the
way it retrieve the package's actual size( not use the content-length of
the http message).

Please feel free to post here if you have any other ideas or concerns
.Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Your description of what we're trying to accomplish is correct.

As to your suggestion to send custom headers, that currently isn't an
option.

We did try experiementing with sending a chunked request since with chunked
requests, no content-length header needs to be specified. I'm able to send a
chunked request, the server receives it, but is not receiving the correct
'end transmission' marker/character from the .net client (sorry not sure what
the correct terminology is). It could be a compatiblity issue between .NET
and Apache, not sure. Any ideas on that one?

[Steven Cheng[MSFT]]

Hi Perry,

Thanks for your followup.
Fortunately, I've just found a certain tech article on making a custom
FileUploader (via HttpWebRequest) on the c-sharpcorner.com ,

#MultipartForm Uploader
http://www.c-sharpcorner.com/Code/20...DotNetBugs.asp

And the author has provided a encapsulated class to do the work(upload file
and other post datas). Also, that article was originally started from the
author's certain project (which need to upload data to a Apache server
rather than IIS). I've also tested the code and that worked well.
You may also have a look. Hope helps.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[PerryG]

Thanks Steve. We'll take a look at the code and see if that'll do the trick.

Perry

"Steven Cheng[MSFT]" wrote:

Hi Perry,

Thanks for your followup.
Fortunately, I've just found a certain tech article on making a custom
FileUploader (via HttpWebRequest) on the c-sharpcorner.com ,

#MultipartForm Uploader
http://www.c-sharpcorner.com/Code/20...DotNetBugs.asp

And the author has provided a encapsulated class to do the work(upload file
and other post datas). Also, that article was originally started from the
author's certain project (which need to upload data to a Apache server
rather than IIS). I've also tested the code and that worked well.
You may also have a look. Hope helps.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Ok. Looking forward to your good news. Good Luck.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)