HttpWebRequest and obsoleted serialization constructor

  • Thread starter Thread starter Ivan Peev
  • Start date Start date
I

Ivan Peev

Hello,

I have question related to HttpWebRequest class, part of System.Net
namespace. Apparently in .NET 2.0 version, the one and only available from
outside constructor is now declared as obsolete (this is a dump from
Reflector):

[Obsolete("Serialization is obsoleted for this type.
http://go.microsoft.com/fwlink/?linkid=14202"),
SecurityPermission(SecurityAction.Demand, SerializationFormatter=true)]
protected HttpWebRequest(SerializationInfo serializationInfo,
StreamingContext streamingContext) : base(serializationInfo,
streamingContext)

I would like to ask the designers of the library why they are obsoleting
this constructor? So far I have found one very good use for it, to implement
my own compressed (gzip) HTTP web request extension. Permanently removing
this constructor will make this simple extension harder to accomplish.

My original reason for using this bizarre constructor was the inability to
use HttpWebRequest constructor with Uri parameter, which is defined as
internal for the assembly. This would have been much better fit for my
problem at hand.

Thank you for your time,
Ivan
 
Ivan said:
Hello,

I have question related to HttpWebRequest class, part of System.Net
namespace. Apparently in .NET 2.0 version, the one and only available
from outside constructor is now declared as obsolete (this is a dump
from Reflector):

[Obsolete("Serialization is obsoleted for this type.
http://go.microsoft.com/fwlink/?linkid=14202"),
SecurityPermission(SecurityAction.Demand,
SerializationFormatter=true)] protected
HttpWebRequest(SerializationInfo serializationInfo, StreamingContext
streamingContext) : base(serializationInfo, streamingContext)

I would like to ask the designers of the library why they are
obsoleting this constructor? So far I have found one very good use
for it, to implement my own compressed (gzip) HTTP web request
extension. Permanently removing this constructor will make this
simple extension harder to accomplish.
Click to expand...

I can't claim credit for designing or implementing it, but to me it
seems you used an internal constructor as an extension point that was
never meant to be (it's sole purpose is to support the serialization
framework).

IMHO to implement compression/decompression support at the request
level is... wrong. Compression is a stream level property, so in order
to offer this kind of functionality, provide a stream decorator that
applies (de)compression to another stream.

BTW, (de)compression support has been added in .NET 2.0.

Cheers,
 
Back
Top