[Rets-dev] Re: RE: RE: FW: .NET implementation with RETS...(originally sent toDWoolley@eneightborhoods.com) (and previous code posting)

mhb1 at se-tel.com mhb1 at se-tel.com
Sat Mar 18 15:16:32 CST 2006


Thanks for the info. I am storing my URIs as strings since I thought this
would give me a performance gain as far as memory space is concerned so I
don't have extra objects floating around...is there a compelling reason I
should use the URI class store all of my URIs? I could not find one, but
if there is a convincing reason why I should, I will re-write this
portion.

Thanks,
Michael McCord
> On Fri, Mar 17, 2006 at 09:48:59PM -0500, mhb1 at se-tel.com wrote:
>> Thanks for your reply. Also, kudo's to Tony at Rapattoni for helping me
>> with this as well. For those of us attempting .NET 1.1SP1
>> implementations:
>>
>> The System.Net.Uri class has two properties which return host
>> information,
>> the property: Host and the property: Authority
>>
>> The difference:
>> "Host" only returns the hostname, not the "hostname:portnumber"
>>
>> If you are trying to connect via System.Net.HTTPWebRequest to a RETS
>> server which only provides paths in its capability URL List (instead of
>> absolute urls) you should use the "Authority" property to complete the
>> first half of the absolute uri needed to make subsequent requests, not
>> "host."
>
> What I would do instead is use the relative URI constructor of the Uri
> class, i.e. in C#:
>
> Uri getMetadataUri = new Uri(loginUri, getMetadataUriString);
>
> This takes care of all the relative path stuff for you, no muss
> no fuss.
>
>  -dbt
>



More information about the Rets-dev mailing list