In the past I've had to deal a lot with line ending problems. I used to work for a software company where their main product was a cross platform (windows, mac, linux) application.

The part that bothers me the most is the "0d 0d 0a" line ending you are talking about. The extra 0d or "0d 0a" doesn't look right at all. Whatever is the reason they are doing that, I don't think the extra line ending should be there.

To answer your question though, I'm not using any proxy between me and the RETS server. I'm testing this from home with a direct connection from me to Comcast to RETS server.

One question I have is why is the server sending windows line endings in the first place? They should be sending "\n" only as pretty much everyone understands that. It seems that they are sending "\n" but are trying to send an extra windows line ending "\r\n" for some reason. I wonder if it sees that the request is coming from a windows box and tries to conform.

AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be wrong.

Anyway, Thank again for your help. I will forward this again to the MRED people and see what they say.

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:13 AM
>
> On Sep 18, 2010, at 8:09 PM, Flavio Smirne wrote:
>
> > Here's a fresh file. From what I can see, it's exactly
> the same as the other file I sent you (unfortunately).
>
> Yes ... same results.
>
> > If you have any ides, let me know. I will send an
> email when I hear back from my vendor (MRED Chicago).
>
> Without knowing exactly how they're constructing the packet
> length, it's hard to say. Here's the extract from the log
> using a hex editor to avoid changing anything:
>
>
>
>
> The 72c at the beginning of the ASCII portion is the
> length. The way chunked encoding works is that the length is
> embedded in the text in ASCII, but it represents a hex value
> of the length. So, 0x72c is the length of data before the
> next length field. The data is terminated by a length field
> containing 0.
>
> I see that line termination is kinda screwey here and that
> could be part of what's going on ... notice the 0d 0d 0a in
> the hex portion after the characters representing the
> length? There is an extra carriage return. This is a
> "Windows-ism" in that CR is used there for line termination.
> The MIME protocol happens to call for CR/LF line termination
> characters. But, so long as the addtional CR it is accounted
> for properly in the length, that shouldn't matter.
>
> Nevertheless, I should expect to see the next length field
> at offset 72c + 6 (to account for the 0d 0d 0a and the
> "72c"). Here's the section surrounding that target offset:
>
>
>
>
> We'd expect the terminating length at 732. In fact, we find
> it at 73c, or 0x0a additional characters into the data
> stream. And, in my playback tool, that's exactly what I
> needed to adjust the length by in order to get the packet
> interpreted properly.
>
> That brings up one more question: are you using a proxy
> server between yourself and the RETS server? If so, could it
> be mucking with the line termination characters? Something
> "Windows-ish" is getting in the way and as I look at this
> today, I see that the 10 (0x0a) additional characters
> exactly matches the # of additional CR characters in the
> RETS response. That's pretty suspicious. :-)
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe.

In the past I've had to deal a lot with line ending problems. I used to work for a software company where their main product was a cross platform (windows, mac, linux) application.

The part that bothers me the most is the "0d 0d 0a" line ending you are talking about. The extra 0d or "0d 0a" doesn't look right at all. Whatever is the reason they are doing that, I don't think the extra line ending should be there.

To answer your question though, I'm not using any proxy between me and the RETS server. I'm testing this from home with a direct connection from me to Comcast to RETS server.

One question I have is why is the server sending windows line endings in the first place? They should be sending "\n" only as pretty much everyone understands that. It seems that they are sending "\n" but are trying to send an extra windows line ending "\r\n" for some reason. I wonder if it sees that the request is coming from a windows box and tries to conform.

AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be wrong.

Anyway, Thank again for your help. I will forward this again to the MRED people and see what they say.

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:13 AM
>
> On Sep 18, 2010, at 8:09 PM, Flavio Smirne wrote:
>
> > Here's a fresh file. From what I can see, it's exactly
> the same as the other file I sent you (unfortunately).
>
> Yes ... same results.
>
> > If you have any ides, let me know. I will send an
> email when I hear back from my vendor (MRED Chicago).
>
> Without knowing exactly how they're constructing the packet
> length, it's hard to say. Here's the extract from the log
> using a hex editor to avoid changing anything:
>
>
>
>
> The 72c at the beginning of the ASCII portion is the
> length. The way chunked encoding works is that the length is
> embedded in the text in ASCII, but it represents a hex value
> of the length. So, 0x72c is the length of data before the
> next length field. The data is terminated by a length field
> containing 0.
>
> I see that line termination is kinda screwey here and that
> could be part of what's going on ... notice the 0d 0d 0a in
> the hex portion after the characters representing the
> length? There is an extra carriage return. This is a
> "Windows-ism" in that CR is used there for line termination.
> The MIME protocol happens to call for CR/LF line termination
> characters. But, so long as the addtional CR it is accounted
> for properly in the length, that shouldn't matter.
>
> Nevertheless, I should expect to see the next length field
> at offset 72c + 6 (to account for the 0d 0d 0a and the
> "72c"). Here's the section surrounding that target offset:
>
>
>
>
> We'd expect the terminating length at 732. In fact, we find
> it at 73c, or 0x0a additional characters into the data
> stream. And, in my playback tool, that's exactly what I
> needed to adjust the length by in order to get the packet
> interpreted properly.
>
> That brings up one more question: are you using a proxy
> server between yourself and the RETS server? If so, could it
> be mucking with the line termination characters? Something
> "Windows-ish" is getting in the way and as I look at this
> today, I see that the 10 (0x0a) additional characters
> exactly matches the # of additional CR characters in the
> RETS response. That's pretty suspicious. :-)
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 12:15 PM, Flavio Smirne wrote:

> One question I have is why is the server sending windows line
> endings in the first place? They should be sending "\n" only as
> pretty much everyone understands that. It seems that they are
> sending "\n" but are trying to send an extra windows line ending "\r
> \n" for some reason.


> The part that bothers me the most is the "0d 0d 0a" line ending you
> are talking about. The extra 0d or "0d 0a" doesn't look right at
> all. Whatever is the reason they are doing that, I don't think the
> extra line ending should be there.

I agree ... that's part of the problem. Depending on the context, the
various standards (including the RETS standard) call for CR/LF line
termination (also see RFC2616, RFC2045 and friends) ... it's that
extra CR causing issues. Note that the normal line termination on Unix
is LF - on Windows, it's CR. That's why I suspect something Windows-
ish is getting in the way.

>
In any event, in this portion of the payload, the line termination is
moot, so long as it is accounted for by the chunked-encoding count.

> AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be
> wrong.

I use FreeBSD and am running the Variman RETS server here. Why don't
you try your application pointing at my server and see what you get? http://www.dis.com:6103/rets/login
. User: Joe Password: Schmoe. If that's successful, we can try a
contrived test with my playback tool where I play back your log to
you ... that might give a clue as to what's adding the extra CR.




_______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe.

In the past I've had to deal a lot with line ending problems. I used to work for a software company where their main product was a cross platform (windows, mac, linux) application.

The part that bothers me the most is the "0d 0d 0a" line ending you are talking about. The extra 0d or "0d 0a" doesn't look right at all. Whatever is the reason they are doing that, I don't think the extra line ending should be there.

To answer your question though, I'm not using any proxy between me and the RETS server. I'm testing this from home with a direct connection from me to Comcast to RETS server.

One question I have is why is the server sending windows line endings in the first place? They should be sending "\n" only as pretty much everyone understands that. It seems that they are sending "\n" but are trying to send an extra windows line ending "\r\n" for some reason. I wonder if it sees that the request is coming from a windows box and tries to conform.

AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be wrong.

Anyway, Thank again for your help. I will forward this again to the MRED people and see what they say.

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:13 AM
>
> On Sep 18, 2010, at 8:09 PM, Flavio Smirne wrote:
>
> > Here's a fresh file. From what I can see, it's exactly
> the same as the other file I sent you (unfortunately).
>
> Yes ... same results.
>
> > If you have any ides, let me know. I will send an
> email when I hear back from my vendor (MRED Chicago).
>
> Without knowing exactly how they're constructing the packet
> length, it's hard to say. Here's the extract from the log
> using a hex editor to avoid changing anything:
>
>
>
>
> The 72c at the beginning of the ASCII portion is the
> length. The way chunked encoding works is that the length is
> embedded in the text in ASCII, but it represents a hex value
> of the length. So, 0x72c is the length of data before the
> next length field. The data is terminated by a length field
> containing 0.
>
> I see that line termination is kinda screwey here and that
> could be part of what's going on ... notice the 0d 0d 0a in
> the hex portion after the characters representing the
> length? There is an extra carriage return. This is a
> "Windows-ism" in that CR is used there for line termination.
> The MIME protocol happens to call for CR/LF line termination
> characters. But, so long as the addtional CR it is accounted
> for properly in the length, that shouldn't matter.
>
> Nevertheless, I should expect to see the next length field
> at offset 72c + 6 (to account for the 0d 0d 0a and the
> "72c"). Here's the section surrounding that target offset:
>
>
>
>
> We'd expect the terminating length at 732. In fact, we find
> it at 73c, or 0x0a additional characters into the data
> stream. And, in my playback tool, that's exactly what I
> needed to adjust the length by in order to get the packet
> interpreted properly.
>
> That brings up one more question: are you using a proxy
> server between yourself and the RETS server? If so, could it
> be mucking with the line termination characters? Something
> "Windows-ish" is getting in the way and as I look at this
> today, I see that the 10 (0x0a) additional characters
> exactly matches the # of additional CR characters in the
> RETS response. That's pretty suspicious. :-)
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 12:15 PM, Flavio Smirne wrote:

> One question I have is why is the server sending windows line
> endings in the first place? They should be sending "\n" only as
> pretty much everyone understands that. It seems that they are
> sending "\n" but are trying to send an extra windows line ending "\r
> \n" for some reason.


> The part that bothers me the most is the "0d 0d 0a" line ending you
> are talking about. The extra 0d or "0d 0a" doesn't look right at
> all. Whatever is the reason they are doing that, I don't think the
> extra line ending should be there.

I agree ... that's part of the problem. Depending on the context, the
various standards (including the RETS standard) call for CR/LF line
termination (also see RFC2616, RFC2045 and friends) ... it's that
extra CR causing issues. Note that the normal line termination on Unix
is LF - on Windows, it's CR. That's why I suspect something Windows-
ish is getting in the way.

>
In any event, in this portion of the payload, the line termination is
moot, so long as it is accounted for by the chunked-encoding count.

> AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be
> wrong.

I use FreeBSD and am running the Variman RETS server here. Why don't
you try your application pointing at my server and see what you get? http://www.dis.com:6103/rets/login
. User: Joe Password: Schmoe. If that's successful, we can try a
contrived test with my playback tool where I play back your log to
you ... that might give a clue as to what's adding the extra CR.




_______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. I'm ready to send a request. Do you want me to request for a specific LN?
Meanwhile, I will log in and see what I can find from your server...

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:02 PM
> On Sep 19, 2010, at 12:15 PM, Flavio
> Smirne wrote:
>
> > One question I have is why is the server sending
> windows line 
> > endings in the first place? They should be sending
> "\n" only as 
> > pretty much everyone understands that. It seems that
> they are 
> > sending "\n" but are trying to send an extra windows
> line ending "\r
> > \n" for some reason.
>
>
> > The part that bothers me the most is the "0d 0d 0a"
> line ending you 
> > are talking about. The extra 0d or "0d 0a" doesn't
> look right at 
> > all. Whatever is the reason they are doing that, I
> don't think the 
> > extra line ending should be there.
>
> I agree ... that's part of the problem. Depending on the
> context, the 
> various standards (including the RETS standard) call for
> CR/LF line 
> termination (also see RFC2616, RFC2045 and friends) ...
> it's that 
> extra CR causing issues. Note that the normal line
> termination on Unix 
> is LF - on Windows, it's CR. That's why I suspect something
> Windows-
> ish is getting in the way.
>
> >
> In any event, in this portion of the payload, the line
> termination is 
> moot, so long as it is accounted for by the
> chunked-encoding count.
>
> > AFAIK, the MRED RETS server runs on a FreeBSD box, but
> I could be 
> > wrong.
>
> I use FreeBSD and am running the Variman RETS server here.
> Why don't 
> you try your application pointing at my server and see what
> you get? http://www.dis.com:6103/rets/login
> . User: Joe Password: Schmoe. If that's successful, we can
> try a 
> contrived test with my playback tool where I play back your
> log to 
> you ... that might give a clue as to what's adding the
> extra CR.
>
>
>
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe.

In the past I've had to deal a lot with line ending problems. I used to work for a software company where their main product was a cross platform (windows, mac, linux) application.

The part that bothers me the most is the "0d 0d 0a" line ending you are talking about. The extra 0d or "0d 0a" doesn't look right at all. Whatever is the reason they are doing that, I don't think the extra line ending should be there.

To answer your question though, I'm not using any proxy between me and the RETS server. I'm testing this from home with a direct connection from me to Comcast to RETS server.

One question I have is why is the server sending windows line endings in the first place? They should be sending "\n" only as pretty much everyone understands that. It seems that they are sending "\n" but are trying to send an extra windows line ending "\r\n" for some reason. I wonder if it sees that the request is coming from a windows box and tries to conform.

AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be wrong.

Anyway, Thank again for your help. I will forward this again to the MRED people and see what they say.

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:13 AM
>
> On Sep 18, 2010, at 8:09 PM, Flavio Smirne wrote:
>
> > Here's a fresh file. From what I can see, it's exactly
> the same as the other file I sent you (unfortunately).
>
> Yes ... same results.
>
> > If you have any ides, let me know. I will send an
> email when I hear back from my vendor (MRED Chicago).
>
> Without knowing exactly how they're constructing the packet
> length, it's hard to say. Here's the extract from the log
> using a hex editor to avoid changing anything:
>
>
>
>
> The 72c at the beginning of the ASCII portion is the
> length. The way chunked encoding works is that the length is
> embedded in the text in ASCII, but it represents a hex value
> of the length. So, 0x72c is the length of data before the
> next length field. The data is terminated by a length field
> containing 0.
>
> I see that line termination is kinda screwey here and that
> could be part of what's going on ... notice the 0d 0d 0a in
> the hex portion after the characters representing the
> length? There is an extra carriage return. This is a
> "Windows-ism" in that CR is used there for line termination.
> The MIME protocol happens to call for CR/LF line termination
> characters. But, so long as the addtional CR it is accounted
> for properly in the length, that shouldn't matter.
>
> Nevertheless, I should expect to see the next length field
> at offset 72c + 6 (to account for the 0d 0d 0a and the
> "72c"). Here's the section surrounding that target offset:
>
>
>
>
> We'd expect the terminating length at 732. In fact, we find
> it at 73c, or 0x0a additional characters into the data
> stream. And, in my playback tool, that's exactly what I
> needed to adjust the length by in order to get the packet
> interpreted properly.
>
> That brings up one more question: are you using a proxy
> server between yourself and the RETS server? If so, could it
> be mucking with the line termination characters? Something
> "Windows-ish" is getting in the way and as I look at this
> today, I see that the 10 (0x0a) additional characters
> exactly matches the # of additional CR characters in the
> RETS response. That's pretty suspicious. :-)
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 12:15 PM, Flavio Smirne wrote:

> One question I have is why is the server sending windows line
> endings in the first place? They should be sending "\n" only as
> pretty much everyone understands that. It seems that they are
> sending "\n" but are trying to send an extra windows line ending "\r
> \n" for some reason.


> The part that bothers me the most is the "0d 0d 0a" line ending you
> are talking about. The extra 0d or "0d 0a" doesn't look right at
> all. Whatever is the reason they are doing that, I don't think the
> extra line ending should be there.

I agree ... that's part of the problem. Depending on the context, the
various standards (including the RETS standard) call for CR/LF line
termination (also see RFC2616, RFC2045 and friends) ... it's that
extra CR causing issues. Note that the normal line termination on Unix
is LF - on Windows, it's CR. That's why I suspect something Windows-
ish is getting in the way.

>
In any event, in this portion of the payload, the line termination is
moot, so long as it is accounted for by the chunked-encoding count.

> AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be
> wrong.

I use FreeBSD and am running the Variman RETS server here. Why don't
you try your application pointing at my server and see what you get? http://www.dis.com:6103/rets/login
. User: Joe Password: Schmoe. If that's successful, we can try a
contrived test with my playback tool where I play back your log to
you ... that might give a clue as to what's adding the extra CR.




_______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. I'm ready to send a request. Do you want me to request for a specific LN?
Meanwhile, I will log in and see what I can find from your server...

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:02 PM
> On Sep 19, 2010, at 12:15 PM, Flavio
> Smirne wrote:
>
> > One question I have is why is the server sending
> windows line 
> > endings in the first place? They should be sending
> "\n" only as 
> > pretty much everyone understands that. It seems that
> they are 
> > sending "\n" but are trying to send an extra windows
> line ending "\r
> > \n" for some reason.
>
>
> > The part that bothers me the most is the "0d 0d 0a"
> line ending you 
> > are talking about. The extra 0d or "0d 0a" doesn't
> look right at 
> > all. Whatever is the reason they are doing that, I
> don't think the 
> > extra line ending should be there.
>
> I agree ... that's part of the problem. Depending on the
> context, the 
> various standards (including the RETS standard) call for
> CR/LF line 
> termination (also see RFC2616, RFC2045 and friends) ...
> it's that 
> extra CR causing issues. Note that the normal line
> termination on Unix 
> is LF - on Windows, it's CR. That's why I suspect something
> Windows-
> ish is getting in the way.
>
> >
> In any event, in this portion of the payload, the line
> termination is 
> moot, so long as it is accounted for by the
> chunked-encoding count.
>
> > AFAIK, the MRED RETS server runs on a FreeBSD box, but
> I could be 
> > wrong.
>
> I use FreeBSD and am running the Variman RETS server here.
> Why don't 
> you try your application pointing at my server and see what
> you get? http://www.dis.com:6103/rets/login
> . User: Joe Password: Schmoe. If that's successful, we can
> try a 
> contrived test with my playback tool where I play back your
> log to 
> you ... that might give a clue as to what's adding the
> extra CR.
>
>
>
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 1:31 PM, Flavio Smirne wrote:

> I'm ready to send a request. Do you want me to request for a
> specific LN?


Try query "(ListPrice=0+)". There are only 5 records to worry about.


> Meanwhile, I will log in and see what I can find from your server...
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:02 PM
>> On Sep 19, 2010, at 12:15 PM, Flavio
>> Smirne wrote:
>>
>>> One question I have is why is the server sending
>> windows line
>>> endings in the first place? They should be sending
>> "\n" only as
>>> pretty much everyone understands that. It seems that
>> they are
>>> sending "\n" but are trying to send an extra windows
>> line ending "\r
>>> \n" for some reason.
>>
>>
>>> The part that bothers me the most is the "0d 0d 0a"
>> line ending you
>>> are talking about. The extra 0d or "0d 0a" doesn't
>> look right at
>>> all. Whatever is the reason they are doing that, I
>> don't think the
>>> extra line ending should be there.
>>
>> I agree ... that's part of the problem. Depending on the
>> context, the
>> various standards (including the RETS standard) call for
>> CR/LF line
>> termination (also see RFC2616, RFC2045 and friends) ...
>> it's that
>> extra CR causing issues. Note that the normal line
>> termination on Unix
>> is LF - on Windows, it's CR. That's why I suspect something
>> Windows-
>> ish is getting in the way.
>>
>>>
>> In any event, in this portion of the payload, the line
>> termination is
>> moot, so long as it is accounted for by the
>> chunked-encoding count.
>>
>>> AFAIK, the MRED RETS server runs on a FreeBSD box, but
>> I could be
>>> wrong.
>>
>> I use FreeBSD and am running the Variman RETS server here.
>> Why don't
>> you try your application pointing at my server and see what
>> you get? http://www.dis.com:6103/rets/login
>> . User: Joe Password: Schmoe. If that's successful, we can
>> try a
>> contrived test with my playback tool where I play back your
>> log to
>> you ... that might give a clue as to what's adding the
>> extra CR.
>>
>>
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe.

In the past I've had to deal a lot with line ending problems. I used to work for a software company where their main product was a cross platform (windows, mac, linux) application.

The part that bothers me the most is the "0d 0d 0a" line ending you are talking about. The extra 0d or "0d 0a" doesn't look right at all. Whatever is the reason they are doing that, I don't think the extra line ending should be there.

To answer your question though, I'm not using any proxy between me and the RETS server. I'm testing this from home with a direct connection from me to Comcast to RETS server.

One question I have is why is the server sending windows line endings in the first place? They should be sending "\n" only as pretty much everyone understands that. It seems that they are sending "\n" but are trying to send an extra windows line ending "\r\n" for some reason. I wonder if it sees that the request is coming from a windows box and tries to conform.

AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be wrong.

Anyway, Thank again for your help. I will forward this again to the MRED people and see what they say.

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:13 AM
>
> On Sep 18, 2010, at 8:09 PM, Flavio Smirne wrote:
>
> > Here's a fresh file. From what I can see, it's exactly
> the same as the other file I sent you (unfortunately).
>
> Yes ... same results.
>
> > If you have any ides, let me know. I will send an
> email when I hear back from my vendor (MRED Chicago).
>
> Without knowing exactly how they're constructing the packet
> length, it's hard to say. Here's the extract from the log
> using a hex editor to avoid changing anything:
>
>
>
>
> The 72c at the beginning of the ASCII portion is the
> length. The way chunked encoding works is that the length is
> embedded in the text in ASCII, but it represents a hex value
> of the length. So, 0x72c is the length of data before the
> next length field. The data is terminated by a length field
> containing 0.
>
> I see that line termination is kinda screwey here and that
> could be part of what's going on ... notice the 0d 0d 0a in
> the hex portion after the characters representing the
> length? There is an extra carriage return. This is a
> "Windows-ism" in that CR is used there for line termination.
> The MIME protocol happens to call for CR/LF line termination
> characters. But, so long as the addtional CR it is accounted
> for properly in the length, that shouldn't matter.
>
> Nevertheless, I should expect to see the next length field
> at offset 72c + 6 (to account for the 0d 0d 0a and the
> "72c"). Here's the section surrounding that target offset:
>
>
>
>
> We'd expect the terminating length at 732. In fact, we find
> it at 73c, or 0x0a additional characters into the data
> stream. And, in my playback tool, that's exactly what I
> needed to adjust the length by in order to get the packet
> interpreted properly.
>
> That brings up one more question: are you using a proxy
> server between yourself and the RETS server? If so, could it
> be mucking with the line termination characters? Something
> "Windows-ish" is getting in the way and as I look at this
> today, I see that the 10 (0x0a) additional characters
> exactly matches the # of additional CR characters in the
> RETS response. That's pretty suspicious. :-)
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 12:15 PM, Flavio Smirne wrote:

> One question I have is why is the server sending windows line
> endings in the first place? They should be sending "\n" only as
> pretty much everyone understands that. It seems that they are
> sending "\n" but are trying to send an extra windows line ending "\r
> \n" for some reason.


> The part that bothers me the most is the "0d 0d 0a" line ending you
> are talking about. The extra 0d or "0d 0a" doesn't look right at
> all. Whatever is the reason they are doing that, I don't think the
> extra line ending should be there.

I agree ... that's part of the problem. Depending on the context, the
various standards (including the RETS standard) call for CR/LF line
termination (also see RFC2616, RFC2045 and friends) ... it's that
extra CR causing issues. Note that the normal line termination on Unix
is LF - on Windows, it's CR. That's why I suspect something Windows-
ish is getting in the way.

>
In any event, in this portion of the payload, the line termination is
moot, so long as it is accounted for by the chunked-encoding count.

> AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be
> wrong.

I use FreeBSD and am running the Variman RETS server here. Why don't
you try your application pointing at my server and see what you get? http://www.dis.com:6103/rets/login
. User: Joe Password: Schmoe. If that's successful, we can try a
contrived test with my playback tool where I play back your log to
you ... that might give a clue as to what's adding the extra CR.




_______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. I'm ready to send a request. Do you want me to request for a specific LN?
Meanwhile, I will log in and see what I can find from your server...

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:02 PM
> On Sep 19, 2010, at 12:15 PM, Flavio
> Smirne wrote:
>
> > One question I have is why is the server sending
> windows line 
> > endings in the first place? They should be sending
> "\n" only as 
> > pretty much everyone understands that. It seems that
> they are 
> > sending "\n" but are trying to send an extra windows
> line ending "\r
> > \n" for some reason.
>
>
> > The part that bothers me the most is the "0d 0d 0a"
> line ending you 
> > are talking about. The extra 0d or "0d 0a" doesn't
> look right at 
> > all. Whatever is the reason they are doing that, I
> don't think the 
> > extra line ending should be there.
>
> I agree ... that's part of the problem. Depending on the
> context, the 
> various standards (including the RETS standard) call for
> CR/LF line 
> termination (also see RFC2616, RFC2045 and friends) ...
> it's that 
> extra CR causing issues. Note that the normal line
> termination on Unix 
> is LF - on Windows, it's CR. That's why I suspect something
> Windows-
> ish is getting in the way.
>
> >
> In any event, in this portion of the payload, the line
> termination is 
> moot, so long as it is accounted for by the
> chunked-encoding count.
>
> > AFAIK, the MRED RETS server runs on a FreeBSD box, but
> I could be 
> > wrong.
>
> I use FreeBSD and am running the Variman RETS server here.
> Why don't 
> you try your application pointing at my server and see what
> you get? http://www.dis.com:6103/rets/login
> . User: Joe Password: Schmoe. If that's successful, we can
> try a 
> contrived test with my playback tool where I play back your
> log to 
> you ... that might give a clue as to what's adding the
> extra CR.
>
>
>
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 1:31 PM, Flavio Smirne wrote:

> I'm ready to send a request. Do you want me to request for a
> specific LN?


Try query "(ListPrice=0+)". There are only 5 records to worry about.


> Meanwhile, I will log in and see what I can find from your server...
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:02 PM
>> On Sep 19, 2010, at 12:15 PM, Flavio
>> Smirne wrote:
>>
>>> One question I have is why is the server sending
>> windows line
>>> endings in the first place? They should be sending
>> "\n" only as
>>> pretty much everyone understands that. It seems that
>> they are
>>> sending "\n" but are trying to send an extra windows
>> line ending "\r
>>> \n" for some reason.
>>
>>
>>> The part that bothers me the most is the "0d 0d 0a"
>> line ending you
>>> are talking about. The extra 0d or "0d 0a" doesn't
>> look right at
>>> all. Whatever is the reason they are doing that, I
>> don't think the
>>> extra line ending should be there.
>>
>> I agree ... that's part of the problem. Depending on the
>> context, the
>> various standards (including the RETS standard) call for
>> CR/LF line
>> termination (also see RFC2616, RFC2045 and friends) ...
>> it's that
>> extra CR causing issues. Note that the normal line
>> termination on Unix
>> is LF - on Windows, it's CR. That's why I suspect something
>> Windows-
>> ish is getting in the way.
>>
>>>
>> In any event, in this portion of the payload, the line
>> termination is
>> moot, so long as it is accounted for by the
>> chunked-encoding count.
>>
>>> AFAIK, the MRED RETS server runs on a FreeBSD box, but
>> I could be
>>> wrong.
>>
>> I use FreeBSD and am running the Variman RETS server here.
>> Why don't
>> you try your application pointing at my server and see what
>> you get? http://www.dis.com:6103/rets/login
>> . User: Joe Password: Schmoe. If that's successful, we can
>> try a
>> contrived test with my playback tool where I play back your
>> log to
>> you ... that might give a clue as to what's adding the
>> extra CR.
>>
>>
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. After playing with the settings, I'm able to retrieve the 5 records with Firefox, but I'm unable to retrieve the records using librets on my .net app.

Here are the details:

Firefox Query:

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=%28ListPrice=0%2B%29&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:





......more data......




.NET query (librets)

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice%3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:



The 2 queries look exactly the same to me, except for the %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Any ideas?


Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:40 PM
> On Sep 19, 2010, at 1:31 PM, Flavio
> Smirne wrote:
>
> > I'm ready to send a request. Do you want me to request
> for a 
> > specific LN?
>
>
> Try query "(ListPrice=0+)". There are only 5 records to
> worry about.
>
>
> > Meanwhile, I will log in and see what I can find from
> your server...
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:02 PM
> >> On Sep 19, 2010, at 12:15 PM, Flavio
> >> Smirne wrote:
> >>
> >>> One question I have is why is the server
> sending
> >> windows line
> >>> endings in the first place? They should be
> sending
> >> "\n" only as
> >>> pretty much everyone understands that. It
> seems that
> >> they are
> >>> sending "\n" but are trying to send an extra
> windows
> >> line ending "\r
> >>> \n" for some reason.
> >>
> >>
> >>> The part that bothers me the most is the "0d
> 0d 0a"
> >> line ending you
> >>> are talking about. The extra 0d or "0d 0a"
> doesn't
> >> look right at
> >>> all. Whatever is the reason they are doing
> that, I
> >> don't think the
> >>> extra line ending should be there.
> >>
> >> I agree ... that's part of the problem. Depending
> on the
> >> context, the
> >> various standards (including the RETS standard)
> call for
> >> CR/LF line
> >> termination (also see RFC2616, RFC2045 and
> friends) ...
> >> it's that
> >> extra CR causing issues. Note that the normal
> line
> >> termination on Unix
> >> is LF - on Windows, it's CR. That's why I suspect
> something
> >> Windows-
> >> ish is getting in the way.
> >>
> >>>
> >> In any event, in this portion of the payload, the
> line
> >> termination is
> >> moot, so long as it is accounted for by the
> >> chunked-encoding count.
> >>
> >>> AFAIK, the MRED RETS server runs on a FreeBSD
> box, but
> >> I could be
> >>> wrong.
> >>
> >> I use FreeBSD and am running the Variman RETS
> server here.
> >> Why don't
> >> you try your application pointing at my server and
> see what
> >> you get? http://www.dis.com:6103/rets/login
> >> . User: Joe Password: Schmoe. If that's
> successful, we can
> >> try a
> >> contrived test with my playback tool where I play
> back your
> >> log to
> >> you ... that might give a clue as to what's adding
> the
> >> extra CR.
> >>
> >>
> >>
> >>
> >> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe.

In the past I've had to deal a lot with line ending problems. I used to work for a software company where their main product was a cross platform (windows, mac, linux) application.

The part that bothers me the most is the "0d 0d 0a" line ending you are talking about. The extra 0d or "0d 0a" doesn't look right at all. Whatever is the reason they are doing that, I don't think the extra line ending should be there.

To answer your question though, I'm not using any proxy between me and the RETS server. I'm testing this from home with a direct connection from me to Comcast to RETS server.

One question I have is why is the server sending windows line endings in the first place? They should be sending "\n" only as pretty much everyone understands that. It seems that they are sending "\n" but are trying to send an extra windows line ending "\r\n" for some reason. I wonder if it sees that the request is coming from a windows box and tries to conform.

AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be wrong.

Anyway, Thank again for your help. I will forward this again to the MRED people and see what they say.

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:13 AM
>
> On Sep 18, 2010, at 8:09 PM, Flavio Smirne wrote:
>
> > Here's a fresh file. From what I can see, it's exactly
> the same as the other file I sent you (unfortunately).
>
> Yes ... same results.
>
> > If you have any ides, let me know. I will send an
> email when I hear back from my vendor (MRED Chicago).
>
> Without knowing exactly how they're constructing the packet
> length, it's hard to say. Here's the extract from the log
> using a hex editor to avoid changing anything:
>
>
>
>
> The 72c at the beginning of the ASCII portion is the
> length. The way chunked encoding works is that the length is
> embedded in the text in ASCII, but it represents a hex value
> of the length. So, 0x72c is the length of data before the
> next length field. The data is terminated by a length field
> containing 0.
>
> I see that line termination is kinda screwey here and that
> could be part of what's going on ... notice the 0d 0d 0a in
> the hex portion after the characters representing the
> length? There is an extra carriage return. This is a
> "Windows-ism" in that CR is used there for line termination.
> The MIME protocol happens to call for CR/LF line termination
> characters. But, so long as the addtional CR it is accounted
> for properly in the length, that shouldn't matter.
>
> Nevertheless, I should expect to see the next length field
> at offset 72c + 6 (to account for the 0d 0d 0a and the
> "72c"). Here's the section surrounding that target offset:
>
>
>
>
> We'd expect the terminating length at 732. In fact, we find
> it at 73c, or 0x0a additional characters into the data
> stream. And, in my playback tool, that's exactly what I
> needed to adjust the length by in order to get the packet
> interpreted properly.
>
> That brings up one more question: are you using a proxy
> server between yourself and the RETS server? If so, could it
> be mucking with the line termination characters? Something
> "Windows-ish" is getting in the way and as I look at this
> today, I see that the 10 (0x0a) additional characters
> exactly matches the # of additional CR characters in the
> RETS response. That's pretty suspicious. :-)
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 12:15 PM, Flavio Smirne wrote:

> One question I have is why is the server sending windows line
> endings in the first place? They should be sending "\n" only as
> pretty much everyone understands that. It seems that they are
> sending "\n" but are trying to send an extra windows line ending "\r
> \n" for some reason.


> The part that bothers me the most is the "0d 0d 0a" line ending you
> are talking about. The extra 0d or "0d 0a" doesn't look right at
> all. Whatever is the reason they are doing that, I don't think the
> extra line ending should be there.

I agree ... that's part of the problem. Depending on the context, the
various standards (including the RETS standard) call for CR/LF line
termination (also see RFC2616, RFC2045 and friends) ... it's that
extra CR causing issues. Note that the normal line termination on Unix
is LF - on Windows, it's CR. That's why I suspect something Windows-
ish is getting in the way.

>
In any event, in this portion of the payload, the line termination is
moot, so long as it is accounted for by the chunked-encoding count.

> AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be
> wrong.

I use FreeBSD and am running the Variman RETS server here. Why don't
you try your application pointing at my server and see what you get? http://www.dis.com:6103/rets/login
. User: Joe Password: Schmoe. If that's successful, we can try a
contrived test with my playback tool where I play back your log to
you ... that might give a clue as to what's adding the extra CR.




_______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. I'm ready to send a request. Do you want me to request for a specific LN?
Meanwhile, I will log in and see what I can find from your server...

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:02 PM
> On Sep 19, 2010, at 12:15 PM, Flavio
> Smirne wrote:
>
> > One question I have is why is the server sending
> windows line 
> > endings in the first place? They should be sending
> "\n" only as 
> > pretty much everyone understands that. It seems that
> they are 
> > sending "\n" but are trying to send an extra windows
> line ending "\r
> > \n" for some reason.
>
>
> > The part that bothers me the most is the "0d 0d 0a"
> line ending you 
> > are talking about. The extra 0d or "0d 0a" doesn't
> look right at 
> > all. Whatever is the reason they are doing that, I
> don't think the 
> > extra line ending should be there.
>
> I agree ... that's part of the problem. Depending on the
> context, the 
> various standards (including the RETS standard) call for
> CR/LF line 
> termination (also see RFC2616, RFC2045 and friends) ...
> it's that 
> extra CR causing issues. Note that the normal line
> termination on Unix 
> is LF - on Windows, it's CR. That's why I suspect something
> Windows-
> ish is getting in the way.
>
> >
> In any event, in this portion of the payload, the line
> termination is 
> moot, so long as it is accounted for by the
> chunked-encoding count.
>
> > AFAIK, the MRED RETS server runs on a FreeBSD box, but
> I could be 
> > wrong.
>
> I use FreeBSD and am running the Variman RETS server here.
> Why don't 
> you try your application pointing at my server and see what
> you get? http://www.dis.com:6103/rets/login
> . User: Joe Password: Schmoe. If that's successful, we can
> try a 
> contrived test with my playback tool where I play back your
> log to 
> you ... that might give a clue as to what's adding the
> extra CR.
>
>
>
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 1:31 PM, Flavio Smirne wrote:

> I'm ready to send a request. Do you want me to request for a
> specific LN?


Try query "(ListPrice=0+)". There are only 5 records to worry about.


> Meanwhile, I will log in and see what I can find from your server...
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:02 PM
>> On Sep 19, 2010, at 12:15 PM, Flavio
>> Smirne wrote:
>>
>>> One question I have is why is the server sending
>> windows line
>>> endings in the first place? They should be sending
>> "\n" only as
>>> pretty much everyone understands that. It seems that
>> they are
>>> sending "\n" but are trying to send an extra windows
>> line ending "\r
>>> \n" for some reason.
>>
>>
>>> The part that bothers me the most is the "0d 0d 0a"
>> line ending you
>>> are talking about. The extra 0d or "0d 0a" doesn't
>> look right at
>>> all. Whatever is the reason they are doing that, I
>> don't think the
>>> extra line ending should be there.
>>
>> I agree ... that's part of the problem. Depending on the
>> context, the
>> various standards (including the RETS standard) call for
>> CR/LF line
>> termination (also see RFC2616, RFC2045 and friends) ...
>> it's that
>> extra CR causing issues. Note that the normal line
>> termination on Unix
>> is LF - on Windows, it's CR. That's why I suspect something
>> Windows-
>> ish is getting in the way.
>>
>>>
>> In any event, in this portion of the payload, the line
>> termination is
>> moot, so long as it is accounted for by the
>> chunked-encoding count.
>>
>>> AFAIK, the MRED RETS server runs on a FreeBSD box, but
>> I could be
>>> wrong.
>>
>> I use FreeBSD and am running the Variman RETS server here.
>> Why don't
>> you try your application pointing at my server and see what
>> you get? http://www.dis.com:6103/rets/login
>> . User: Joe Password: Schmoe. If that's successful, we can
>> try a
>> contrived test with my playback tool where I play back your
>> log to
>> you ... that might give a clue as to what's adding the
>> extra CR.
>>
>>
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. After playing with the settings, I'm able to retrieve the 5 records with Firefox, but I'm unable to retrieve the records using librets on my .net app.

Here are the details:

Firefox Query:

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=%28ListPrice=0%2B%29&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:





......more data......




.NET query (librets)

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice%3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:



The 2 queries look exactly the same to me, except for the %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Any ideas?


Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:40 PM
> On Sep 19, 2010, at 1:31 PM, Flavio
> Smirne wrote:
>
> > I'm ready to send a request. Do you want me to request
> for a 
> > specific LN?
>
>
> Try query "(ListPrice=0+)". There are only 5 records to
> worry about.
>
>
> > Meanwhile, I will log in and see what I can find from
> your server...
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:02 PM
> >> On Sep 19, 2010, at 12:15 PM, Flavio
> >> Smirne wrote:
> >>
> >>> One question I have is why is the server
> sending
> >> windows line
> >>> endings in the first place? They should be
> sending
> >> "\n" only as
> >>> pretty much everyone understands that. It
> seems that
> >> they are
> >>> sending "\n" but are trying to send an extra
> windows
> >> line ending "\r
> >>> \n" for some reason.
> >>
> >>
> >>> The part that bothers me the most is the "0d
> 0d 0a"
> >> line ending you
> >>> are talking about. The extra 0d or "0d 0a"
> doesn't
> >> look right at
> >>> all. Whatever is the reason they are doing
> that, I
> >> don't think the
> >>> extra line ending should be there.
> >>
> >> I agree ... that's part of the problem. Depending
> on the
> >> context, the
> >> various standards (including the RETS standard)
> call for
> >> CR/LF line
> >> termination (also see RFC2616, RFC2045 and
> friends) ...
> >> it's that
> >> extra CR causing issues. Note that the normal
> line
> >> termination on Unix
> >> is LF - on Windows, it's CR. That's why I suspect
> something
> >> Windows-
> >> ish is getting in the way.
> >>
> >>>
> >> In any event, in this portion of the payload, the
> line
> >> termination is
> >> moot, so long as it is accounted for by the
> >> chunked-encoding count.
> >>
> >>> AFAIK, the MRED RETS server runs on a FreeBSD
> box, but
> >> I could be
> >>> wrong.
> >>
> >> I use FreeBSD and am running the Variman RETS
> server here.
> >> Why don't
> >> you try your application pointing at my server and
> see what
> >> you get? http://www.dis.com:6103/rets/login
> >> . User: Joe Password: Schmoe. If that's
> successful, we can
> >> try a
> >> contrived test with my playback tool where I play
> back your
> >> log to
> >> you ... that might give a clue as to what's adding
> the
> >> extra CR.
> >>
> >>
> >>
> >>
> >> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 2:24 PM, Flavio Smirne wrote:

> .NET query (librets)
>
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
>
> Answer:
>
>

You're not setting the RETS version on the client side, so it is
defaulting to 1.0. On the server side, Variman no longer supports RETS
1.0, hence the error.

> The 2 queries look exactly the same to me, except for the
> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Are you doing any encoding or just letting libRETS handle it? This
almost looks like it's double encoded.

>
> Any ideas?
>
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:40 PM
>> On Sep 19, 2010, at 1:31 PM, Flavio
>> Smirne wrote:
>>
>>> I'm ready to send a request. Do you want me to request
>> for a
>>> specific LN?
>>
>>
>> Try query "(ListPrice=0+)". There are only 5 records to
>> worry about.
>>
>>
>>> Meanwhile, I will log in and see what I can find from
>> your server...
>>>
>>> Flavio
>>>
>>> --- On Sun, 9/19/10, Mark Klein <>
>> wrote:
>>>
>>>> From: Mark Klein <>
>>>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
>> File
>>>> To: "For discussion and help for and by the users
>> of the libRETS C+
>>>> + library"
>>>> Date: Sunday, September 19, 2010, 3:02 PM
>>>> On Sep 19, 2010, at 12:15 PM, Flavio
>>>> Smirne wrote:
>>>>
>>>>> One question I have is why is the server
>> sending
>>>> windows line
>>>>> endings in the first place? They should be
>> sending
>>>> "\n" only as
>>>>> pretty much everyone understands that. It
>> seems that
>>>> they are
>>>>> sending "\n" but are trying to send an extra
>> windows
>>>> line ending "\r
>>>>> \n" for some reason.
>>>>
>>>>
>>>>> The part that bothers me the most is the "0d
>> 0d 0a"
>>>> line ending you
>>>>> are talking about. The extra 0d or "0d 0a"
>> doesn't
>>>> look right at
>>>>> all. Whatever is the reason they are doing
>> that, I
>>>> don't think the
>>>>> extra line ending should be there.
>>>>
>>>> I agree ... that's part of the problem. Depending
>> on the
>>>> context, the
>>>> various standards (including the RETS standard)
>> call for
>>>> CR/LF line
>>>> termination (also see RFC2616, RFC2045 and
>> friends) ...
>>>> it's that
>>>> extra CR causing issues. Note that the normal
>> line
>>>> termination on Unix
>>>> is LF - on Windows, it's CR. That's why I suspect
>> something
>>>> Windows-
>>>> ish is getting in the way.
>>>>
>>>>>
>>>> In any event, in this portion of the payload, the
>> line
>>>> termination is
>>>> moot, so long as it is accounted for by the
>>>> chunked-encoding count.
>>>>
>>>>> AFAIK, the MRED RETS server runs on a FreeBSD
>> box, but
>>>> I could be
>>>>> wrong.
>>>>
>>>> I use FreeBSD and am running the Variman RETS
>> server here.
>>>> Why don't
>>>> you try your application pointing at my server and
>> see what
>>>> you get? http://www.dis.com:6103/rets/login
>>>> . User: Joe Password: Schmoe. If that's
>> successful, we can
>>>> try a
>>>> contrived test with my playback tool where I play
>> back your
>>>> log to
>>>> you ... that might give a clue as to what's adding
>> the
>>>> extra CR.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe.

In the past I've had to deal a lot with line ending problems. I used to work for a software company where their main product was a cross platform (windows, mac, linux) application.

The part that bothers me the most is the "0d 0d 0a" line ending you are talking about. The extra 0d or "0d 0a" doesn't look right at all. Whatever is the reason they are doing that, I don't think the extra line ending should be there.

To answer your question though, I'm not using any proxy between me and the RETS server. I'm testing this from home with a direct connection from me to Comcast to RETS server.

One question I have is why is the server sending windows line endings in the first place? They should be sending "\n" only as pretty much everyone understands that. It seems that they are sending "\n" but are trying to send an extra windows line ending "\r\n" for some reason. I wonder if it sees that the request is coming from a windows box and tries to conform.

AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be wrong.

Anyway, Thank again for your help. I will forward this again to the MRED people and see what they say.

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:13 AM
>
> On Sep 18, 2010, at 8:09 PM, Flavio Smirne wrote:
>
> > Here's a fresh file. From what I can see, it's exactly
> the same as the other file I sent you (unfortunately).
>
> Yes ... same results.
>
> > If you have any ides, let me know. I will send an
> email when I hear back from my vendor (MRED Chicago).
>
> Without knowing exactly how they're constructing the packet
> length, it's hard to say. Here's the extract from the log
> using a hex editor to avoid changing anything:
>
>
>
>
> The 72c at the beginning of the ASCII portion is the
> length. The way chunked encoding works is that the length is
> embedded in the text in ASCII, but it represents a hex value
> of the length. So, 0x72c is the length of data before the
> next length field. The data is terminated by a length field
> containing 0.
>
> I see that line termination is kinda screwey here and that
> could be part of what's going on ... notice the 0d 0d 0a in
> the hex portion after the characters representing the
> length? There is an extra carriage return. This is a
> "Windows-ism" in that CR is used there for line termination.
> The MIME protocol happens to call for CR/LF line termination
> characters. But, so long as the addtional CR it is accounted
> for properly in the length, that shouldn't matter.
>
> Nevertheless, I should expect to see the next length field
> at offset 72c + 6 (to account for the 0d 0d 0a and the
> "72c"). Here's the section surrounding that target offset:
>
>
>
>
> We'd expect the terminating length at 732. In fact, we find
> it at 73c, or 0x0a additional characters into the data
> stream. And, in my playback tool, that's exactly what I
> needed to adjust the length by in order to get the packet
> interpreted properly.
>
> That brings up one more question: are you using a proxy
> server between yourself and the RETS server? If so, could it
> be mucking with the line termination characters? Something
> "Windows-ish" is getting in the way and as I look at this
> today, I see that the 10 (0x0a) additional characters
> exactly matches the # of additional CR characters in the
> RETS response. That's pretty suspicious. :-)
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 12:15 PM, Flavio Smirne wrote:

> One question I have is why is the server sending windows line
> endings in the first place? They should be sending "\n" only as
> pretty much everyone understands that. It seems that they are
> sending "\n" but are trying to send an extra windows line ending "\r
> \n" for some reason.


> The part that bothers me the most is the "0d 0d 0a" line ending you
> are talking about. The extra 0d or "0d 0a" doesn't look right at
> all. Whatever is the reason they are doing that, I don't think the
> extra line ending should be there.

I agree ... that's part of the problem. Depending on the context, the
various standards (including the RETS standard) call for CR/LF line
termination (also see RFC2616, RFC2045 and friends) ... it's that
extra CR causing issues. Note that the normal line termination on Unix
is LF - on Windows, it's CR. That's why I suspect something Windows-
ish is getting in the way.

>
In any event, in this portion of the payload, the line termination is
moot, so long as it is accounted for by the chunked-encoding count.

> AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be
> wrong.

I use FreeBSD and am running the Variman RETS server here. Why don't
you try your application pointing at my server and see what you get? http://www.dis.com:6103/rets/login
. User: Joe Password: Schmoe. If that's successful, we can try a
contrived test with my playback tool where I play back your log to
you ... that might give a clue as to what's adding the extra CR.




_______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. I'm ready to send a request. Do you want me to request for a specific LN?
Meanwhile, I will log in and see what I can find from your server...

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:02 PM
> On Sep 19, 2010, at 12:15 PM, Flavio
> Smirne wrote:
>
> > One question I have is why is the server sending
> windows line 
> > endings in the first place? They should be sending
> "\n" only as 
> > pretty much everyone understands that. It seems that
> they are 
> > sending "\n" but are trying to send an extra windows
> line ending "\r
> > \n" for some reason.
>
>
> > The part that bothers me the most is the "0d 0d 0a"
> line ending you 
> > are talking about. The extra 0d or "0d 0a" doesn't
> look right at 
> > all. Whatever is the reason they are doing that, I
> don't think the 
> > extra line ending should be there.
>
> I agree ... that's part of the problem. Depending on the
> context, the 
> various standards (including the RETS standard) call for
> CR/LF line 
> termination (also see RFC2616, RFC2045 and friends) ...
> it's that 
> extra CR causing issues. Note that the normal line
> termination on Unix 
> is LF - on Windows, it's CR. That's why I suspect something
> Windows-
> ish is getting in the way.
>
> >
> In any event, in this portion of the payload, the line
> termination is 
> moot, so long as it is accounted for by the
> chunked-encoding count.
>
> > AFAIK, the MRED RETS server runs on a FreeBSD box, but
> I could be 
> > wrong.
>
> I use FreeBSD and am running the Variman RETS server here.
> Why don't 
> you try your application pointing at my server and see what
> you get? http://www.dis.com:6103/rets/login
> . User: Joe Password: Schmoe. If that's successful, we can
> try a 
> contrived test with my playback tool where I play back your
> log to 
> you ... that might give a clue as to what's adding the
> extra CR.
>
>
>
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 1:31 PM, Flavio Smirne wrote:

> I'm ready to send a request. Do you want me to request for a
> specific LN?


Try query "(ListPrice=0+)". There are only 5 records to worry about.


> Meanwhile, I will log in and see what I can find from your server...
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:02 PM
>> On Sep 19, 2010, at 12:15 PM, Flavio
>> Smirne wrote:
>>
>>> One question I have is why is the server sending
>> windows line
>>> endings in the first place? They should be sending
>> "\n" only as
>>> pretty much everyone understands that. It seems that
>> they are
>>> sending "\n" but are trying to send an extra windows
>> line ending "\r
>>> \n" for some reason.
>>
>>
>>> The part that bothers me the most is the "0d 0d 0a"
>> line ending you
>>> are talking about. The extra 0d or "0d 0a" doesn't
>> look right at
>>> all. Whatever is the reason they are doing that, I
>> don't think the
>>> extra line ending should be there.
>>
>> I agree ... that's part of the problem. Depending on the
>> context, the
>> various standards (including the RETS standard) call for
>> CR/LF line
>> termination (also see RFC2616, RFC2045 and friends) ...
>> it's that
>> extra CR causing issues. Note that the normal line
>> termination on Unix
>> is LF - on Windows, it's CR. That's why I suspect something
>> Windows-
>> ish is getting in the way.
>>
>>>
>> In any event, in this portion of the payload, the line
>> termination is
>> moot, so long as it is accounted for by the
>> chunked-encoding count.
>>
>>> AFAIK, the MRED RETS server runs on a FreeBSD box, but
>> I could be
>>> wrong.
>>
>> I use FreeBSD and am running the Variman RETS server here.
>> Why don't
>> you try your application pointing at my server and see what
>> you get? http://www.dis.com:6103/rets/login
>> . User: Joe Password: Schmoe. If that's successful, we can
>> try a
>> contrived test with my playback tool where I play back your
>> log to
>> you ... that might give a clue as to what's adding the
>> extra CR.
>>
>>
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. After playing with the settings, I'm able to retrieve the 5 records with Firefox, but I'm unable to retrieve the records using librets on my .net app.

Here are the details:

Firefox Query:

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=%28ListPrice=0%2B%29&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:





......more data......




.NET query (librets)

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice%3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:



The 2 queries look exactly the same to me, except for the %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Any ideas?


Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:40 PM
> On Sep 19, 2010, at 1:31 PM, Flavio
> Smirne wrote:
>
> > I'm ready to send a request. Do you want me to request
> for a 
> > specific LN?
>
>
> Try query "(ListPrice=0+)". There are only 5 records to
> worry about.
>
>
> > Meanwhile, I will log in and see what I can find from
> your server...
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:02 PM
> >> On Sep 19, 2010, at 12:15 PM, Flavio
> >> Smirne wrote:
> >>
> >>> One question I have is why is the server
> sending
> >> windows line
> >>> endings in the first place? They should be
> sending
> >> "\n" only as
> >>> pretty much everyone understands that. It
> seems that
> >> they are
> >>> sending "\n" but are trying to send an extra
> windows
> >> line ending "\r
> >>> \n" for some reason.
> >>
> >>
> >>> The part that bothers me the most is the "0d
> 0d 0a"
> >> line ending you
> >>> are talking about. The extra 0d or "0d 0a"
> doesn't
> >> look right at
> >>> all. Whatever is the reason they are doing
> that, I
> >> don't think the
> >>> extra line ending should be there.
> >>
> >> I agree ... that's part of the problem. Depending
> on the
> >> context, the
> >> various standards (including the RETS standard)
> call for
> >> CR/LF line
> >> termination (also see RFC2616, RFC2045 and
> friends) ...
> >> it's that
> >> extra CR causing issues. Note that the normal
> line
> >> termination on Unix
> >> is LF - on Windows, it's CR. That's why I suspect
> something
> >> Windows-
> >> ish is getting in the way.
> >>
> >>>
> >> In any event, in this portion of the payload, the
> line
> >> termination is
> >> moot, so long as it is accounted for by the
> >> chunked-encoding count.
> >>
> >>> AFAIK, the MRED RETS server runs on a FreeBSD
> box, but
> >> I could be
> >>> wrong.
> >>
> >> I use FreeBSD and am running the Variman RETS
> server here.
> >> Why don't
> >> you try your application pointing at my server and
> see what
> >> you get? http://www.dis.com:6103/rets/login
> >> . User: Joe Password: Schmoe. If that's
> successful, we can
> >> try a
> >> contrived test with my playback tool where I play
> back your
> >> log to
> >> you ... that might give a clue as to what's adding
> the
> >> extra CR.
> >>
> >>
> >>
> >>
> >> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 2:24 PM, Flavio Smirne wrote:

> .NET query (librets)
>
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
>
> Answer:
>
>

You're not setting the RETS version on the client side, so it is
defaulting to 1.0. On the server side, Variman no longer supports RETS
1.0, hence the error.

> The 2 queries look exactly the same to me, except for the
> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Are you doing any encoding or just letting libRETS handle it? This
almost looks like it's double encoded.

>
> Any ideas?
>
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:40 PM
>> On Sep 19, 2010, at 1:31 PM, Flavio
>> Smirne wrote:
>>
>>> I'm ready to send a request. Do you want me to request
>> for a
>>> specific LN?
>>
>>
>> Try query "(ListPrice=0+)". There are only 5 records to
>> worry about.
>>
>>
>>> Meanwhile, I will log in and see what I can find from
>> your server...
>>>
>>> Flavio
>>>
>>> --- On Sun, 9/19/10, Mark Klein <>
>> wrote:
>>>
>>>> From: Mark Klein <>
>>>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
>> File
>>>> To: "For discussion and help for and by the users
>> of the libRETS C+
>>>> + library"
>>>> Date: Sunday, September 19, 2010, 3:02 PM
>>>> On Sep 19, 2010, at 12:15 PM, Flavio
>>>> Smirne wrote:
>>>>
>>>>> One question I have is why is the server
>> sending
>>>> windows line
>>>>> endings in the first place? They should be
>> sending
>>>> "\n" only as
>>>>> pretty much everyone understands that. It
>> seems that
>>>> they are
>>>>> sending "\n" but are trying to send an extra
>> windows
>>>> line ending "\r
>>>>> \n" for some reason.
>>>>
>>>>
>>>>> The part that bothers me the most is the "0d
>> 0d 0a"
>>>> line ending you
>>>>> are talking about. The extra 0d or "0d 0a"
>> doesn't
>>>> look right at
>>>>> all. Whatever is the reason they are doing
>> that, I
>>>> don't think the
>>>>> extra line ending should be there.
>>>>
>>>> I agree ... that's part of the problem. Depending
>> on the
>>>> context, the
>>>> various standards (including the RETS standard)
>> call for
>>>> CR/LF line
>>>> termination (also see RFC2616, RFC2045 and
>> friends) ...
>>>> it's that
>>>> extra CR causing issues. Note that the normal
>> line
>>>> termination on Unix
>>>> is LF - on Windows, it's CR. That's why I suspect
>> something
>>>> Windows-
>>>> ish is getting in the way.
>>>>
>>>>>
>>>> In any event, in this portion of the payload, the
>> line
>>>> termination is
>>>> moot, so long as it is accounted for by the
>>>> chunked-encoding count.
>>>>
>>>>> AFAIK, the MRED RETS server runs on a FreeBSD
>> box, but
>>>> I could be
>>>>> wrong.
>>>>
>>>> I use FreeBSD and am running the Variman RETS
>> server here.
>>>> Why don't
>>>> you try your application pointing at my server and
>> see what
>>>> you get? http://www.dis.com:6103/rets/login
>>>> . User: Joe Password: Schmoe. If that's
>> successful, we can
>>>> try a
>>>> contrived test with my playback tool where I play
>> back your
>>>> log to
>>>> you ... that might give a clue as to what's adding
>> the
>>>> extra CR.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. Awesome! After setting the version and getting rid of the double encoding, everything worked fine.

I wonder if the original problem wasn't related to me not setting the version... I will try playing with that as well...

I'm sending the log to you at librets-logs (at) crt.realtors.org

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 4:54 PM
> On Sep 19, 2010, at 2:24 PM, Flavio
> Smirne wrote:
>
> > .NET query (librets)
> >
> >
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
>
> >
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
> >
> > Answer:
> >
> >
>
> You're not setting the RETS version on the client side, so
> it is 
> defaulting to 1.0. On the server side, Variman no longer
> supports RETS 
> 1.0, hence the error.
>
> > The 2 queries look exactly the same to me, except for
> the 
> > %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
>
> Are you doing any encoding or just letting libRETS handle
> it? This 
> almost looks like it's double encoded.
>
> >
> > Any ideas?
> >
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:40 PM
> >> On Sep 19, 2010, at 1:31 PM, Flavio
> >> Smirne wrote:
> >>
> >>> I'm ready to send a request. Do you want me to
> request
> >> for a
> >>> specific LN?
> >>
> >>
> >> Try query "(ListPrice=0+)". There are only 5
> records to
> >> worry about.
> >>
> >>
> >>> Meanwhile, I will log in and see what I can
> find from
> >> your server...
> >>>
> >>> Flavio
> >>>
> >>> --- On Sun, 9/19/10, Mark Klein <>
> >> wrote:
> >>>
> >>>> From: Mark Klein <>
> >>>> Subject: Re: [libRETS-users] [ezRETS-logs]
> New Log
> >> File
> >>>> To: "For discussion and help for and by
> the users
> >> of the libRETS C+
> >>>> + library"
> >>>> Date: Sunday, September 19, 2010, 3:02 PM
> >>>> On Sep 19, 2010, at 12:15 PM, Flavio
> >>>> Smirne wrote:
> >>>>
> >>>>> One question I have is why is the
> server
> >> sending
> >>>> windows line
> >>>>> endings in the first place? They
> should be
> >> sending
> >>>> "\n" only as
> >>>>> pretty much everyone understands that.
> It
> >> seems that
> >>>> they are
> >>>>> sending "\n" but are trying to send an
> extra
> >> windows
> >>>> line ending "\r
> >>>>> \n" for some reason.
> >>>>
> >>>>
> >>>>> The part that bothers me the most is
> the "0d
> >> 0d 0a"
> >>>> line ending you
> >>>>> are talking about. The extra 0d or "0d
> 0a"
> >> doesn't
> >>>> look right at
> >>>>> all. Whatever is the reason they are
> doing
> >> that, I
> >>>> don't think the
> >>>>> extra line ending should be there.
> >>>>
> >>>> I agree ... that's part of the problem.
> Depending
> >> on the
> >>>> context, the
> >>>> various standards (including the RETS
> standard)
> >> call for
> >>>> CR/LF line
> >>>> termination (also see RFC2616, RFC2045
> and
> >> friends) ...
> >>>> it's that
> >>>> extra CR causing issues. Note that the
> normal
> >> line
> >>>> termination on Unix
> >>>> is LF - on Windows, it's CR. That's why I
> suspect
> >> something
> >>>> Windows-
> >>>> ish is getting in the way.
> >>>>
> >>>>>
> >>>> In any event, in this portion of the
> payload, the
> >> line
> >>>> termination is
> >>>> moot, so long as it is accounted for by
> the
> >>>> chunked-encoding count.
> >>>>
> >>>>> AFAIK, the MRED RETS server runs on a
> FreeBSD
> >> box, but
> >>>> I could be
> >>>>> wrong.
> >>>>
> >>>> I use FreeBSD and am running the Variman
> RETS
> >> server here.
> >>>> Why don't
> >>>> you try your application pointing at my
> server and
> >> see what
> >>>> you get? http://www.dis.com:6103/rets/login
> >>>> . User: Joe Password: Schmoe. If that's
> >> successful, we can
> >>>> try a
> >>>> contrived test with my playback tool where
> I play
> >> back your
> >>>> log to
> >>>> you ... that might give a clue as to
> what's adding
> >> the
> >>>> extra CR.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe.

In the past I've had to deal a lot with line ending problems. I used to work for a software company where their main product was a cross platform (windows, mac, linux) application.

The part that bothers me the most is the "0d 0d 0a" line ending you are talking about. The extra 0d or "0d 0a" doesn't look right at all. Whatever is the reason they are doing that, I don't think the extra line ending should be there.

To answer your question though, I'm not using any proxy between me and the RETS server. I'm testing this from home with a direct connection from me to Comcast to RETS server.

One question I have is why is the server sending windows line endings in the first place? They should be sending "\n" only as pretty much everyone understands that. It seems that they are sending "\n" but are trying to send an extra windows line ending "\r\n" for some reason. I wonder if it sees that the request is coming from a windows box and tries to conform.

AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be wrong.

Anyway, Thank again for your help. I will forward this again to the MRED people and see what they say.

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:13 AM
>
> On Sep 18, 2010, at 8:09 PM, Flavio Smirne wrote:
>
> > Here's a fresh file. From what I can see, it's exactly
> the same as the other file I sent you (unfortunately).
>
> Yes ... same results.
>
> > If you have any ides, let me know. I will send an
> email when I hear back from my vendor (MRED Chicago).
>
> Without knowing exactly how they're constructing the packet
> length, it's hard to say. Here's the extract from the log
> using a hex editor to avoid changing anything:
>
>
>
>
> The 72c at the beginning of the ASCII portion is the
> length. The way chunked encoding works is that the length is
> embedded in the text in ASCII, but it represents a hex value
> of the length. So, 0x72c is the length of data before the
> next length field. The data is terminated by a length field
> containing 0.
>
> I see that line termination is kinda screwey here and that
> could be part of what's going on ... notice the 0d 0d 0a in
> the hex portion after the characters representing the
> length? There is an extra carriage return. This is a
> "Windows-ism" in that CR is used there for line termination.
> The MIME protocol happens to call for CR/LF line termination
> characters. But, so long as the addtional CR it is accounted
> for properly in the length, that shouldn't matter.
>
> Nevertheless, I should expect to see the next length field
> at offset 72c + 6 (to account for the 0d 0d 0a and the
> "72c"). Here's the section surrounding that target offset:
>
>
>
>
> We'd expect the terminating length at 732. In fact, we find
> it at 73c, or 0x0a additional characters into the data
> stream. And, in my playback tool, that's exactly what I
> needed to adjust the length by in order to get the packet
> interpreted properly.
>
> That brings up one more question: are you using a proxy
> server between yourself and the RETS server? If so, could it
> be mucking with the line termination characters? Something
> "Windows-ish" is getting in the way and as I look at this
> today, I see that the 10 (0x0a) additional characters
> exactly matches the # of additional CR characters in the
> RETS response. That's pretty suspicious. :-)
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 12:15 PM, Flavio Smirne wrote:

> One question I have is why is the server sending windows line
> endings in the first place? They should be sending "\n" only as
> pretty much everyone understands that. It seems that they are
> sending "\n" but are trying to send an extra windows line ending "\r
> \n" for some reason.


> The part that bothers me the most is the "0d 0d 0a" line ending you
> are talking about. The extra 0d or "0d 0a" doesn't look right at
> all. Whatever is the reason they are doing that, I don't think the
> extra line ending should be there.

I agree ... that's part of the problem. Depending on the context, the
various standards (including the RETS standard) call for CR/LF line
termination (also see RFC2616, RFC2045 and friends) ... it's that
extra CR causing issues. Note that the normal line termination on Unix
is LF - on Windows, it's CR. That's why I suspect something Windows-
ish is getting in the way.

>
In any event, in this portion of the payload, the line termination is
moot, so long as it is accounted for by the chunked-encoding count.

> AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be
> wrong.

I use FreeBSD and am running the Variman RETS server here. Why don't
you try your application pointing at my server and see what you get? http://www.dis.com:6103/rets/login
. User: Joe Password: Schmoe. If that's successful, we can try a
contrived test with my playback tool where I play back your log to
you ... that might give a clue as to what's adding the extra CR.




_______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. I'm ready to send a request. Do you want me to request for a specific LN?
Meanwhile, I will log in and see what I can find from your server...

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:02 PM
> On Sep 19, 2010, at 12:15 PM, Flavio
> Smirne wrote:
>
> > One question I have is why is the server sending
> windows line 
> > endings in the first place? They should be sending
> "\n" only as 
> > pretty much everyone understands that. It seems that
> they are 
> > sending "\n" but are trying to send an extra windows
> line ending "\r
> > \n" for some reason.
>
>
> > The part that bothers me the most is the "0d 0d 0a"
> line ending you 
> > are talking about. The extra 0d or "0d 0a" doesn't
> look right at 
> > all. Whatever is the reason they are doing that, I
> don't think the 
> > extra line ending should be there.
>
> I agree ... that's part of the problem. Depending on the
> context, the 
> various standards (including the RETS standard) call for
> CR/LF line 
> termination (also see RFC2616, RFC2045 and friends) ...
> it's that 
> extra CR causing issues. Note that the normal line
> termination on Unix 
> is LF - on Windows, it's CR. That's why I suspect something
> Windows-
> ish is getting in the way.
>
> >
> In any event, in this portion of the payload, the line
> termination is 
> moot, so long as it is accounted for by the
> chunked-encoding count.
>
> > AFAIK, the MRED RETS server runs on a FreeBSD box, but
> I could be 
> > wrong.
>
> I use FreeBSD and am running the Variman RETS server here.
> Why don't 
> you try your application pointing at my server and see what
> you get? http://www.dis.com:6103/rets/login
> . User: Joe Password: Schmoe. If that's successful, we can
> try a 
> contrived test with my playback tool where I play back your
> log to 
> you ... that might give a clue as to what's adding the
> extra CR.
>
>
>
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 1:31 PM, Flavio Smirne wrote:

> I'm ready to send a request. Do you want me to request for a
> specific LN?


Try query "(ListPrice=0+)". There are only 5 records to worry about.


> Meanwhile, I will log in and see what I can find from your server...
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:02 PM
>> On Sep 19, 2010, at 12:15 PM, Flavio
>> Smirne wrote:
>>
>>> One question I have is why is the server sending
>> windows line
>>> endings in the first place? They should be sending
>> "\n" only as
>>> pretty much everyone understands that. It seems that
>> they are
>>> sending "\n" but are trying to send an extra windows
>> line ending "\r
>>> \n" for some reason.
>>
>>
>>> The part that bothers me the most is the "0d 0d 0a"
>> line ending you
>>> are talking about. The extra 0d or "0d 0a" doesn't
>> look right at
>>> all. Whatever is the reason they are doing that, I
>> don't think the
>>> extra line ending should be there.
>>
>> I agree ... that's part of the problem. Depending on the
>> context, the
>> various standards (including the RETS standard) call for
>> CR/LF line
>> termination (also see RFC2616, RFC2045 and friends) ...
>> it's that
>> extra CR causing issues. Note that the normal line
>> termination on Unix
>> is LF - on Windows, it's CR. That's why I suspect something
>> Windows-
>> ish is getting in the way.
>>
>>>
>> In any event, in this portion of the payload, the line
>> termination is
>> moot, so long as it is accounted for by the
>> chunked-encoding count.
>>
>>> AFAIK, the MRED RETS server runs on a FreeBSD box, but
>> I could be
>>> wrong.
>>
>> I use FreeBSD and am running the Variman RETS server here.
>> Why don't
>> you try your application pointing at my server and see what
>> you get? http://www.dis.com:6103/rets/login
>> . User: Joe Password: Schmoe. If that's successful, we can
>> try a
>> contrived test with my playback tool where I play back your
>> log to
>> you ... that might give a clue as to what's adding the
>> extra CR.
>>
>>
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. After playing with the settings, I'm able to retrieve the 5 records with Firefox, but I'm unable to retrieve the records using librets on my .net app.

Here are the details:

Firefox Query:

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=%28ListPrice=0%2B%29&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:





......more data......




.NET query (librets)

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice%3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:



The 2 queries look exactly the same to me, except for the %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Any ideas?


Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:40 PM
> On Sep 19, 2010, at 1:31 PM, Flavio
> Smirne wrote:
>
> > I'm ready to send a request. Do you want me to request
> for a 
> > specific LN?
>
>
> Try query "(ListPrice=0+)". There are only 5 records to
> worry about.
>
>
> > Meanwhile, I will log in and see what I can find from
> your server...
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:02 PM
> >> On Sep 19, 2010, at 12:15 PM, Flavio
> >> Smirne wrote:
> >>
> >>> One question I have is why is the server
> sending
> >> windows line
> >>> endings in the first place? They should be
> sending
> >> "\n" only as
> >>> pretty much everyone understands that. It
> seems that
> >> they are
> >>> sending "\n" but are trying to send an extra
> windows
> >> line ending "\r
> >>> \n" for some reason.
> >>
> >>
> >>> The part that bothers me the most is the "0d
> 0d 0a"
> >> line ending you
> >>> are talking about. The extra 0d or "0d 0a"
> doesn't
> >> look right at
> >>> all. Whatever is the reason they are doing
> that, I
> >> don't think the
> >>> extra line ending should be there.
> >>
> >> I agree ... that's part of the problem. Depending
> on the
> >> context, the
> >> various standards (including the RETS standard)
> call for
> >> CR/LF line
> >> termination (also see RFC2616, RFC2045 and
> friends) ...
> >> it's that
> >> extra CR causing issues. Note that the normal
> line
> >> termination on Unix
> >> is LF - on Windows, it's CR. That's why I suspect
> something
> >> Windows-
> >> ish is getting in the way.
> >>
> >>>
> >> In any event, in this portion of the payload, the
> line
> >> termination is
> >> moot, so long as it is accounted for by the
> >> chunked-encoding count.
> >>
> >>> AFAIK, the MRED RETS server runs on a FreeBSD
> box, but
> >> I could be
> >>> wrong.
> >>
> >> I use FreeBSD and am running the Variman RETS
> server here.
> >> Why don't
> >> you try your application pointing at my server and
> see what
> >> you get? http://www.dis.com:6103/rets/login
> >> . User: Joe Password: Schmoe. If that's
> successful, we can
> >> try a
> >> contrived test with my playback tool where I play
> back your
> >> log to
> >> you ... that might give a clue as to what's adding
> the
> >> extra CR.
> >>
> >>
> >>
> >>
> >> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 2:24 PM, Flavio Smirne wrote:

> .NET query (librets)
>
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
>
> Answer:
>
>

You're not setting the RETS version on the client side, so it is
defaulting to 1.0. On the server side, Variman no longer supports RETS
1.0, hence the error.

> The 2 queries look exactly the same to me, except for the
> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Are you doing any encoding or just letting libRETS handle it? This
almost looks like it's double encoded.

>
> Any ideas?
>
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:40 PM
>> On Sep 19, 2010, at 1:31 PM, Flavio
>> Smirne wrote:
>>
>>> I'm ready to send a request. Do you want me to request
>> for a
>>> specific LN?
>>
>>
>> Try query "(ListPrice=0+)". There are only 5 records to
>> worry about.
>>
>>
>>> Meanwhile, I will log in and see what I can find from
>> your server...
>>>
>>> Flavio
>>>
>>> --- On Sun, 9/19/10, Mark Klein <>
>> wrote:
>>>
>>>> From: Mark Klein <>
>>>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
>> File
>>>> To: "For discussion and help for and by the users
>> of the libRETS C+
>>>> + library"
>>>> Date: Sunday, September 19, 2010, 3:02 PM
>>>> On Sep 19, 2010, at 12:15 PM, Flavio
>>>> Smirne wrote:
>>>>
>>>>> One question I have is why is the server
>> sending
>>>> windows line
>>>>> endings in the first place? They should be
>> sending
>>>> "\n" only as
>>>>> pretty much everyone understands that. It
>> seems that
>>>> they are
>>>>> sending "\n" but are trying to send an extra
>> windows
>>>> line ending "\r
>>>>> \n" for some reason.
>>>>
>>>>
>>>>> The part that bothers me the most is the "0d
>> 0d 0a"
>>>> line ending you
>>>>> are talking about. The extra 0d or "0d 0a"
>> doesn't
>>>> look right at
>>>>> all. Whatever is the reason they are doing
>> that, I
>>>> don't think the
>>>>> extra line ending should be there.
>>>>
>>>> I agree ... that's part of the problem. Depending
>> on the
>>>> context, the
>>>> various standards (including the RETS standard)
>> call for
>>>> CR/LF line
>>>> termination (also see RFC2616, RFC2045 and
>> friends) ...
>>>> it's that
>>>> extra CR causing issues. Note that the normal
>> line
>>>> termination on Unix
>>>> is LF - on Windows, it's CR. That's why I suspect
>> something
>>>> Windows-
>>>> ish is getting in the way.
>>>>
>>>>>
>>>> In any event, in this portion of the payload, the
>> line
>>>> termination is
>>>> moot, so long as it is accounted for by the
>>>> chunked-encoding count.
>>>>
>>>>> AFAIK, the MRED RETS server runs on a FreeBSD
>> box, but
>>>> I could be
>>>>> wrong.
>>>>
>>>> I use FreeBSD and am running the Variman RETS
>> server here.
>>>> Why don't
>>>> you try your application pointing at my server and
>> see what
>>>> you get? http://www.dis.com:6103/rets/login
>>>> . User: Joe Password: Schmoe. If that's
>> successful, we can
>>>> try a
>>>> contrived test with my playback tool where I play
>> back your
>>>> log to
>>>> you ... that might give a clue as to what's adding
>> the
>>>> extra CR.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. Awesome! After setting the version and getting rid of the double encoding, everything worked fine.

I wonder if the original problem wasn't related to me not setting the version... I will try playing with that as well...

I'm sending the log to you at librets-logs (at) crt.realtors.org

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 4:54 PM
> On Sep 19, 2010, at 2:24 PM, Flavio
> Smirne wrote:
>
> > .NET query (librets)
> >
> >
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
>
> >
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
> >
> > Answer:
> >
> >
>
> You're not setting the RETS version on the client side, so
> it is 
> defaulting to 1.0. On the server side, Variman no longer
> supports RETS 
> 1.0, hence the error.
>
> > The 2 queries look exactly the same to me, except for
> the 
> > %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
>
> Are you doing any encoding or just letting libRETS handle
> it? This 
> almost looks like it's double encoded.
>
> >
> > Any ideas?
> >
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:40 PM
> >> On Sep 19, 2010, at 1:31 PM, Flavio
> >> Smirne wrote:
> >>
> >>> I'm ready to send a request. Do you want me to
> request
> >> for a
> >>> specific LN?
> >>
> >>
> >> Try query "(ListPrice=0+)". There are only 5
> records to
> >> worry about.
> >>
> >>
> >>> Meanwhile, I will log in and see what I can
> find from
> >> your server...
> >>>
> >>> Flavio
> >>>
> >>> --- On Sun, 9/19/10, Mark Klein <>
> >> wrote:
> >>>
> >>>> From: Mark Klein <>
> >>>> Subject: Re: [libRETS-users] [ezRETS-logs]
> New Log
> >> File
> >>>> To: "For discussion and help for and by
> the users
> >> of the libRETS C+
> >>>> + library"
> >>>> Date: Sunday, September 19, 2010, 3:02 PM
> >>>> On Sep 19, 2010, at 12:15 PM, Flavio
> >>>> Smirne wrote:
> >>>>
> >>>>> One question I have is why is the
> server
> >> sending
> >>>> windows line
> >>>>> endings in the first place? They
> should be
> >> sending
> >>>> "\n" only as
> >>>>> pretty much everyone understands that.
> It
> >> seems that
> >>>> they are
> >>>>> sending "\n" but are trying to send an
> extra
> >> windows
> >>>> line ending "\r
> >>>>> \n" for some reason.
> >>>>
> >>>>
> >>>>> The part that bothers me the most is
> the "0d
> >> 0d 0a"
> >>>> line ending you
> >>>>> are talking about. The extra 0d or "0d
> 0a"
> >> doesn't
> >>>> look right at
> >>>>> all. Whatever is the reason they are
> doing
> >> that, I
> >>>> don't think the
> >>>>> extra line ending should be there.
> >>>>
> >>>> I agree ... that's part of the problem.
> Depending
> >> on the
> >>>> context, the
> >>>> various standards (including the RETS
> standard)
> >> call for
> >>>> CR/LF line
> >>>> termination (also see RFC2616, RFC2045
> and
> >> friends) ...
> >>>> it's that
> >>>> extra CR causing issues. Note that the
> normal
> >> line
> >>>> termination on Unix
> >>>> is LF - on Windows, it's CR. That's why I
> suspect
> >> something
> >>>> Windows-
> >>>> ish is getting in the way.
> >>>>
> >>>>>
> >>>> In any event, in this portion of the
> payload, the
> >> line
> >>>> termination is
> >>>> moot, so long as it is accounted for by
> the
> >>>> chunked-encoding count.
> >>>>
> >>>>> AFAIK, the MRED RETS server runs on a
> FreeBSD
> >> box, but
> >>>> I could be
> >>>>> wrong.
> >>>>
> >>>> I use FreeBSD and am running the Variman
> RETS
> >> server here.
> >>>> Why don't
> >>>> you try your application pointing at my
> server and
> >> see what
> >>>> you get? http://www.dis.com:6103/rets/login
> >>>> . User: Joe Password: Schmoe. If that's
> >> successful, we can
> >>>> try a
> >>>> contrived test with my playback tool where
> I play
> >> back your
> >>>> log to
> >>>> you ... that might give a clue as to
> what's adding
> >> the
> >>>> extra CR.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 3:07 PM, Flavio Smirne wrote:

> Awesome! After setting the version and getting rid of the double
> encoding, everything worked fine.
>
> I wonder if the original problem wasn't related to me not setting
> the version... I will try playing with that as well...

I don't see how the version differences would cause the server to send
invalid chunked-encoded data. Nevertheless, it's worth a try.

>
> I'm sending the log to you at librets-logs (at) crt.realtors.org

I was concerned that your system was the one adding the extra CR ..
it's not. The log you sent me this last time was formatted exactly as
I would expect. It is supposed to be the raw data seen by libCURL
(which we use to abstract away all the html goo) and since this log is
exactly what I expected, I'm convinced it is the server side adding
the extra characters and not accounting for them.


>
> Flavio
>
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 4:54 PM
>> On Sep 19, 2010, at 2:24 PM, Flavio
>> Smirne wrote:
>>
>>> .NET query (librets)
>>>
>>>
>> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
>>
>>>
>> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
>>>
>>> Answer:
>>>
>>>
>>
>> You're not setting the RETS version on the client side, so
>> it is
>> defaulting to 1.0. On the server side, Variman no longer
>> supports RETS
>> 1.0, hence the error.
>>
>>> The 2 queries look exactly the same to me, except for
>> the
>>> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
>>
>> Are you doing any encoding or just letting libRETS handle
>> it? This
>> almost looks like it's double encoded.
>>
>>>
>>> Any ideas?
>>>
>>>
>>> Flavio
>>>
>>> --- On Sun, 9/19/10, Mark Klein <>
>> wrote:
>>>
>>>> From: Mark Klein <>
>>>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
>> File
>>>> To: "For discussion and help for and by the users
>> of the libRETS C+
>>>> + library"
>>>> Date: Sunday, September 19, 2010, 3:40 PM
>>>> On Sep 19, 2010, at 1:31 PM, Flavio
>>>> Smirne wrote:
>>>>
>>>>> I'm ready to send a request. Do you want me to
>> request
>>>> for a
>>>>> specific LN?
>>>>
>>>>
>>>> Try query "(ListPrice=0+)". There are only 5
>> records to
>>>> worry about.
>>>>
>>>>
>>>>> Meanwhile, I will log in and see what I can
>> find from
>>>> your server...
>>>>>
>>>>> Flavio
>>>>>
>>>>> --- On Sun, 9/19/10, Mark Klein <>
>>>> wrote:
>>>>>
>>>>>> From: Mark Klein <>
>>>>>> Subject: Re: [libRETS-users] [ezRETS-logs]
>> New Log
>>>> File
>>>>>> To: "For discussion and help for and by
>> the users
>>>> of the libRETS C+
>>>>>> + library"
>>>>>> Date: Sunday, September 19, 2010, 3:02 PM
>>>>>> On Sep 19, 2010, at 12:15 PM, Flavio
>>>>>> Smirne wrote:
>>>>>>
>>>>>>> One question I have is why is the
>> server
>>>> sending
>>>>>> windows line
>>>>>>> endings in the first place? They
>> should be
>>>> sending
>>>>>> "\n" only as
>>>>>>> pretty much everyone understands that.
>> It
>>>> seems that
>>>>>> they are
>>>>>>> sending "\n" but are trying to send an
>> extra
>>>> windows
>>>>>> line ending "\r
>>>>>>> \n" for some reason.
>>>>>>
>>>>>>
>>>>>>> The part that bothers me the most is
>> the "0d
>>>> 0d 0a"
>>>>>> line ending you
>>>>>>> are talking about. The extra 0d or "0d
>> 0a"
>>>> doesn't
>>>>>> look right at
>>>>>>> all. Whatever is the reason they are
>> doing
>>>> that, I
>>>>>> don't think the
>>>>>>> extra line ending should be there.
>>>>>>
>>>>>> I agree ... that's part of the problem.
>> Depending
>>>> on the
>>>>>> context, the
>>>>>> various standards (including the RETS
>> standard)
>>>> call for
>>>>>> CR/LF line
>>>>>> termination (also see RFC2616, RFC2045
>> and
>>>> friends) ...
>>>>>> it's that
>>>>>> extra CR causing issues. Note that the
>> normal
>>>> line
>>>>>> termination on Unix
>>>>>> is LF - on Windows, it's CR. That's why I
>> suspect
>>>> something
>>>>>> Windows-
>>>>>> ish is getting in the way.
>>>>>>
>>>>>>>
>>>>>> In any event, in this portion of the
>> payload, the
>>>> line
>>>>>> termination is
>>>>>> moot, so long as it is accounted for by
>> the
>>>>>> chunked-encoding count.
>>>>>>
>>>>>>> AFAIK, the MRED RETS server runs on a
>> FreeBSD
>>>> box, but
>>>>>> I could be
>>>>>>> wrong.
>>>>>>
>>>>>> I use FreeBSD and am running the Variman
>> RETS
>>>> server here.
>>>>>> Why don't
>>>>>> you try your application pointing at my
>> server and
>>>> see what
>>>>>> you get? http://www.dis.com:6103/rets/login
>>>>>> . User: Joe Password: Schmoe. If that's
>>>> successful, we can
>>>>>> try a
>>>>>> contrived test with my playback tool where
>> I play
>>>> back your
>>>>>> log to
>>>>>> you ... that might give a clue as to
>> what's adding
>>>> the
>>>>>> extra CR.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe.

In the past I've had to deal a lot with line ending problems. I used to work for a software company where their main product was a cross platform (windows, mac, linux) application.

The part that bothers me the most is the "0d 0d 0a" line ending you are talking about. The extra 0d or "0d 0a" doesn't look right at all. Whatever is the reason they are doing that, I don't think the extra line ending should be there.

To answer your question though, I'm not using any proxy between me and the RETS server. I'm testing this from home with a direct connection from me to Comcast to RETS server.

One question I have is why is the server sending windows line endings in the first place? They should be sending "\n" only as pretty much everyone understands that. It seems that they are sending "\n" but are trying to send an extra windows line ending "\r\n" for some reason. I wonder if it sees that the request is coming from a windows box and tries to conform.

AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be wrong.

Anyway, Thank again for your help. I will forward this again to the MRED people and see what they say.

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:13 AM
>
> On Sep 18, 2010, at 8:09 PM, Flavio Smirne wrote:
>
> > Here's a fresh file. From what I can see, it's exactly
> the same as the other file I sent you (unfortunately).
>
> Yes ... same results.
>
> > If you have any ides, let me know. I will send an
> email when I hear back from my vendor (MRED Chicago).
>
> Without knowing exactly how they're constructing the packet
> length, it's hard to say. Here's the extract from the log
> using a hex editor to avoid changing anything:
>
>
>
>
> The 72c at the beginning of the ASCII portion is the
> length. The way chunked encoding works is that the length is
> embedded in the text in ASCII, but it represents a hex value
> of the length. So, 0x72c is the length of data before the
> next length field. The data is terminated by a length field
> containing 0.
>
> I see that line termination is kinda screwey here and that
> could be part of what's going on ... notice the 0d 0d 0a in
> the hex portion after the characters representing the
> length? There is an extra carriage return. This is a
> "Windows-ism" in that CR is used there for line termination.
> The MIME protocol happens to call for CR/LF line termination
> characters. But, so long as the addtional CR it is accounted
> for properly in the length, that shouldn't matter.
>
> Nevertheless, I should expect to see the next length field
> at offset 72c + 6 (to account for the 0d 0d 0a and the
> "72c"). Here's the section surrounding that target offset:
>
>
>
>
> We'd expect the terminating length at 732. In fact, we find
> it at 73c, or 0x0a additional characters into the data
> stream. And, in my playback tool, that's exactly what I
> needed to adjust the length by in order to get the packet
> interpreted properly.
>
> That brings up one more question: are you using a proxy
> server between yourself and the RETS server? If so, could it
> be mucking with the line termination characters? Something
> "Windows-ish" is getting in the way and as I look at this
> today, I see that the 10 (0x0a) additional characters
> exactly matches the # of additional CR characters in the
> RETS response. That's pretty suspicious. :-)
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 12:15 PM, Flavio Smirne wrote:

> One question I have is why is the server sending windows line
> endings in the first place? They should be sending "\n" only as
> pretty much everyone understands that. It seems that they are
> sending "\n" but are trying to send an extra windows line ending "\r
> \n" for some reason.


> The part that bothers me the most is the "0d 0d 0a" line ending you
> are talking about. The extra 0d or "0d 0a" doesn't look right at
> all. Whatever is the reason they are doing that, I don't think the
> extra line ending should be there.

I agree ... that's part of the problem. Depending on the context, the
various standards (including the RETS standard) call for CR/LF line
termination (also see RFC2616, RFC2045 and friends) ... it's that
extra CR causing issues. Note that the normal line termination on Unix
is LF - on Windows, it's CR. That's why I suspect something Windows-
ish is getting in the way.

>
In any event, in this portion of the payload, the line termination is
moot, so long as it is accounted for by the chunked-encoding count.

> AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be
> wrong.

I use FreeBSD and am running the Variman RETS server here. Why don't
you try your application pointing at my server and see what you get? http://www.dis.com:6103/rets/login
. User: Joe Password: Schmoe. If that's successful, we can try a
contrived test with my playback tool where I play back your log to
you ... that might give a clue as to what's adding the extra CR.




_______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. I'm ready to send a request. Do you want me to request for a specific LN?
Meanwhile, I will log in and see what I can find from your server...

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:02 PM
> On Sep 19, 2010, at 12:15 PM, Flavio
> Smirne wrote:
>
> > One question I have is why is the server sending
> windows line 
> > endings in the first place? They should be sending
> "\n" only as 
> > pretty much everyone understands that. It seems that
> they are 
> > sending "\n" but are trying to send an extra windows
> line ending "\r
> > \n" for some reason.
>
>
> > The part that bothers me the most is the "0d 0d 0a"
> line ending you 
> > are talking about. The extra 0d or "0d 0a" doesn't
> look right at 
> > all. Whatever is the reason they are doing that, I
> don't think the 
> > extra line ending should be there.
>
> I agree ... that's part of the problem. Depending on the
> context, the 
> various standards (including the RETS standard) call for
> CR/LF line 
> termination (also see RFC2616, RFC2045 and friends) ...
> it's that 
> extra CR causing issues. Note that the normal line
> termination on Unix 
> is LF - on Windows, it's CR. That's why I suspect something
> Windows-
> ish is getting in the way.
>
> >
> In any event, in this portion of the payload, the line
> termination is 
> moot, so long as it is accounted for by the
> chunked-encoding count.
>
> > AFAIK, the MRED RETS server runs on a FreeBSD box, but
> I could be 
> > wrong.
>
> I use FreeBSD and am running the Variman RETS server here.
> Why don't 
> you try your application pointing at my server and see what
> you get? http://www.dis.com:6103/rets/login
> . User: Joe Password: Schmoe. If that's successful, we can
> try a 
> contrived test with my playback tool where I play back your
> log to 
> you ... that might give a clue as to what's adding the
> extra CR.
>
>
>
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 1:31 PM, Flavio Smirne wrote:

> I'm ready to send a request. Do you want me to request for a
> specific LN?


Try query "(ListPrice=0+)". There are only 5 records to worry about.


> Meanwhile, I will log in and see what I can find from your server...
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:02 PM
>> On Sep 19, 2010, at 12:15 PM, Flavio
>> Smirne wrote:
>>
>>> One question I have is why is the server sending
>> windows line
>>> endings in the first place? They should be sending
>> "\n" only as
>>> pretty much everyone understands that. It seems that
>> they are
>>> sending "\n" but are trying to send an extra windows
>> line ending "\r
>>> \n" for some reason.
>>
>>
>>> The part that bothers me the most is the "0d 0d 0a"
>> line ending you
>>> are talking about. The extra 0d or "0d 0a" doesn't
>> look right at
>>> all. Whatever is the reason they are doing that, I
>> don't think the
>>> extra line ending should be there.
>>
>> I agree ... that's part of the problem. Depending on the
>> context, the
>> various standards (including the RETS standard) call for
>> CR/LF line
>> termination (also see RFC2616, RFC2045 and friends) ...
>> it's that
>> extra CR causing issues. Note that the normal line
>> termination on Unix
>> is LF - on Windows, it's CR. That's why I suspect something
>> Windows-
>> ish is getting in the way.
>>
>>>
>> In any event, in this portion of the payload, the line
>> termination is
>> moot, so long as it is accounted for by the
>> chunked-encoding count.
>>
>>> AFAIK, the MRED RETS server runs on a FreeBSD box, but
>> I could be
>>> wrong.
>>
>> I use FreeBSD and am running the Variman RETS server here.
>> Why don't
>> you try your application pointing at my server and see what
>> you get? http://www.dis.com:6103/rets/login
>> . User: Joe Password: Schmoe. If that's successful, we can
>> try a
>> contrived test with my playback tool where I play back your
>> log to
>> you ... that might give a clue as to what's adding the
>> extra CR.
>>
>>
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. After playing with the settings, I'm able to retrieve the 5 records with Firefox, but I'm unable to retrieve the records using librets on my .net app.

Here are the details:

Firefox Query:

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=%28ListPrice=0%2B%29&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:





......more data......




.NET query (librets)

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice%3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:



The 2 queries look exactly the same to me, except for the %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Any ideas?


Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:40 PM
> On Sep 19, 2010, at 1:31 PM, Flavio
> Smirne wrote:
>
> > I'm ready to send a request. Do you want me to request
> for a 
> > specific LN?
>
>
> Try query "(ListPrice=0+)". There are only 5 records to
> worry about.
>
>
> > Meanwhile, I will log in and see what I can find from
> your server...
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:02 PM
> >> On Sep 19, 2010, at 12:15 PM, Flavio
> >> Smirne wrote:
> >>
> >>> One question I have is why is the server
> sending
> >> windows line
> >>> endings in the first place? They should be
> sending
> >> "\n" only as
> >>> pretty much everyone understands that. It
> seems that
> >> they are
> >>> sending "\n" but are trying to send an extra
> windows
> >> line ending "\r
> >>> \n" for some reason.
> >>
> >>
> >>> The part that bothers me the most is the "0d
> 0d 0a"
> >> line ending you
> >>> are talking about. The extra 0d or "0d 0a"
> doesn't
> >> look right at
> >>> all. Whatever is the reason they are doing
> that, I
> >> don't think the
> >>> extra line ending should be there.
> >>
> >> I agree ... that's part of the problem. Depending
> on the
> >> context, the
> >> various standards (including the RETS standard)
> call for
> >> CR/LF line
> >> termination (also see RFC2616, RFC2045 and
> friends) ...
> >> it's that
> >> extra CR causing issues. Note that the normal
> line
> >> termination on Unix
> >> is LF - on Windows, it's CR. That's why I suspect
> something
> >> Windows-
> >> ish is getting in the way.
> >>
> >>>
> >> In any event, in this portion of the payload, the
> line
> >> termination is
> >> moot, so long as it is accounted for by the
> >> chunked-encoding count.
> >>
> >>> AFAIK, the MRED RETS server runs on a FreeBSD
> box, but
> >> I could be
> >>> wrong.
> >>
> >> I use FreeBSD and am running the Variman RETS
> server here.
> >> Why don't
> >> you try your application pointing at my server and
> see what
> >> you get? http://www.dis.com:6103/rets/login
> >> . User: Joe Password: Schmoe. If that's
> successful, we can
> >> try a
> >> contrived test with my playback tool where I play
> back your
> >> log to
> >> you ... that might give a clue as to what's adding
> the
> >> extra CR.
> >>
> >>
> >>
> >>
> >> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 2:24 PM, Flavio Smirne wrote:

> .NET query (librets)
>
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
>
> Answer:
>
>

You're not setting the RETS version on the client side, so it is
defaulting to 1.0. On the server side, Variman no longer supports RETS
1.0, hence the error.

> The 2 queries look exactly the same to me, except for the
> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Are you doing any encoding or just letting libRETS handle it? This
almost looks like it's double encoded.

>
> Any ideas?
>
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:40 PM
>> On Sep 19, 2010, at 1:31 PM, Flavio
>> Smirne wrote:
>>
>>> I'm ready to send a request. Do you want me to request
>> for a
>>> specific LN?
>>
>>
>> Try query "(ListPrice=0+)". There are only 5 records to
>> worry about.
>>
>>
>>> Meanwhile, I will log in and see what I can find from
>> your server...
>>>
>>> Flavio
>>>
>>> --- On Sun, 9/19/10, Mark Klein <>
>> wrote:
>>>
>>>> From: Mark Klein <>
>>>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
>> File
>>>> To: "For discussion and help for and by the users
>> of the libRETS C+
>>>> + library"
>>>> Date: Sunday, September 19, 2010, 3:02 PM
>>>> On Sep 19, 2010, at 12:15 PM, Flavio
>>>> Smirne wrote:
>>>>
>>>>> One question I have is why is the server
>> sending
>>>> windows line
>>>>> endings in the first place? They should be
>> sending
>>>> "\n" only as
>>>>> pretty much everyone understands that. It
>> seems that
>>>> they are
>>>>> sending "\n" but are trying to send an extra
>> windows
>>>> line ending "\r
>>>>> \n" for some reason.
>>>>
>>>>
>>>>> The part that bothers me the most is the "0d
>> 0d 0a"
>>>> line ending you
>>>>> are talking about. The extra 0d or "0d 0a"
>> doesn't
>>>> look right at
>>>>> all. Whatever is the reason they are doing
>> that, I
>>>> don't think the
>>>>> extra line ending should be there.
>>>>
>>>> I agree ... that's part of the problem. Depending
>> on the
>>>> context, the
>>>> various standards (including the RETS standard)
>> call for
>>>> CR/LF line
>>>> termination (also see RFC2616, RFC2045 and
>> friends) ...
>>>> it's that
>>>> extra CR causing issues. Note that the normal
>> line
>>>> termination on Unix
>>>> is LF - on Windows, it's CR. That's why I suspect
>> something
>>>> Windows-
>>>> ish is getting in the way.
>>>>
>>>>>
>>>> In any event, in this portion of the payload, the
>> line
>>>> termination is
>>>> moot, so long as it is accounted for by the
>>>> chunked-encoding count.
>>>>
>>>>> AFAIK, the MRED RETS server runs on a FreeBSD
>> box, but
>>>> I could be
>>>>> wrong.
>>>>
>>>> I use FreeBSD and am running the Variman RETS
>> server here.
>>>> Why don't
>>>> you try your application pointing at my server and
>> see what
>>>> you get? http://www.dis.com:6103/rets/login
>>>> . User: Joe Password: Schmoe. If that's
>> successful, we can
>>>> try a
>>>> contrived test with my playback tool where I play
>> back your
>>>> log to
>>>> you ... that might give a clue as to what's adding
>> the
>>>> extra CR.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. Awesome! After setting the version and getting rid of the double encoding, everything worked fine.

I wonder if the original problem wasn't related to me not setting the version... I will try playing with that as well...

I'm sending the log to you at librets-logs (at) crt.realtors.org

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 4:54 PM
> On Sep 19, 2010, at 2:24 PM, Flavio
> Smirne wrote:
>
> > .NET query (librets)
> >
> >
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
>
> >
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
> >
> > Answer:
> >
> >
>
> You're not setting the RETS version on the client side, so
> it is 
> defaulting to 1.0. On the server side, Variman no longer
> supports RETS 
> 1.0, hence the error.
>
> > The 2 queries look exactly the same to me, except for
> the 
> > %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
>
> Are you doing any encoding or just letting libRETS handle
> it? This 
> almost looks like it's double encoded.
>
> >
> > Any ideas?
> >
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:40 PM
> >> On Sep 19, 2010, at 1:31 PM, Flavio
> >> Smirne wrote:
> >>
> >>> I'm ready to send a request. Do you want me to
> request
> >> for a
> >>> specific LN?
> >>
> >>
> >> Try query "(ListPrice=0+)". There are only 5
> records to
> >> worry about.
> >>
> >>
> >>> Meanwhile, I will log in and see what I can
> find from
> >> your server...
> >>>
> >>> Flavio
> >>>
> >>> --- On Sun, 9/19/10, Mark Klein <>
> >> wrote:
> >>>
> >>>> From: Mark Klein <>
> >>>> Subject: Re: [libRETS-users] [ezRETS-logs]
> New Log
> >> File
> >>>> To: "For discussion and help for and by
> the users
> >> of the libRETS C+
> >>>> + library"
> >>>> Date: Sunday, September 19, 2010, 3:02 PM
> >>>> On Sep 19, 2010, at 12:15 PM, Flavio
> >>>> Smirne wrote:
> >>>>
> >>>>> One question I have is why is the
> server
> >> sending
> >>>> windows line
> >>>>> endings in the first place? They
> should be
> >> sending
> >>>> "\n" only as
> >>>>> pretty much everyone understands that.
> It
> >> seems that
> >>>> they are
> >>>>> sending "\n" but are trying to send an
> extra
> >> windows
> >>>> line ending "\r
> >>>>> \n" for some reason.
> >>>>
> >>>>
> >>>>> The part that bothers me the most is
> the "0d
> >> 0d 0a"
> >>>> line ending you
> >>>>> are talking about. The extra 0d or "0d
> 0a"
> >> doesn't
> >>>> look right at
> >>>>> all. Whatever is the reason they are
> doing
> >> that, I
> >>>> don't think the
> >>>>> extra line ending should be there.
> >>>>
> >>>> I agree ... that's part of the problem.
> Depending
> >> on the
> >>>> context, the
> >>>> various standards (including the RETS
> standard)
> >> call for
> >>>> CR/LF line
> >>>> termination (also see RFC2616, RFC2045
> and
> >> friends) ...
> >>>> it's that
> >>>> extra CR causing issues. Note that the
> normal
> >> line
> >>>> termination on Unix
> >>>> is LF - on Windows, it's CR. That's why I
> suspect
> >> something
> >>>> Windows-
> >>>> ish is getting in the way.
> >>>>
> >>>>>
> >>>> In any event, in this portion of the
> payload, the
> >> line
> >>>> termination is
> >>>> moot, so long as it is accounted for by
> the
> >>>> chunked-encoding count.
> >>>>
> >>>>> AFAIK, the MRED RETS server runs on a
> FreeBSD
> >> box, but
> >>>> I could be
> >>>>> wrong.
> >>>>
> >>>> I use FreeBSD and am running the Variman
> RETS
> >> server here.
> >>>> Why don't
> >>>> you try your application pointing at my
> server and
> >> see what
> >>>> you get? http://www.dis.com:6103/rets/login
> >>>> . User: Joe Password: Schmoe. If that's
> >> successful, we can
> >>>> try a
> >>>> contrived test with my playback tool where
> I play
> >> back your
> >>>> log to
> >>>> you ... that might give a clue as to
> what's adding
> >> the
> >>>> extra CR.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 3:07 PM, Flavio Smirne wrote:

> Awesome! After setting the version and getting rid of the double
> encoding, everything worked fine.
>
> I wonder if the original problem wasn't related to me not setting
> the version... I will try playing with that as well...

I don't see how the version differences would cause the server to send
invalid chunked-encoded data. Nevertheless, it's worth a try.

>
> I'm sending the log to you at librets-logs (at) crt.realtors.org

I was concerned that your system was the one adding the extra CR ..
it's not. The log you sent me this last time was formatted exactly as
I would expect. It is supposed to be the raw data seen by libCURL
(which we use to abstract away all the html goo) and since this log is
exactly what I expected, I'm convinced it is the server side adding
the extra characters and not accounting for them.


>
> Flavio
>
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 4:54 PM
>> On Sep 19, 2010, at 2:24 PM, Flavio
>> Smirne wrote:
>>
>>> .NET query (librets)
>>>
>>>
>> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
>>
>>>
>> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
>>>
>>> Answer:
>>>
>>>
>>
>> You're not setting the RETS version on the client side, so
>> it is
>> defaulting to 1.0. On the server side, Variman no longer
>> supports RETS
>> 1.0, hence the error.
>>
>>> The 2 queries look exactly the same to me, except for
>> the
>>> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
>>
>> Are you doing any encoding or just letting libRETS handle
>> it? This
>> almost looks like it's double encoded.
>>
>>>
>>> Any ideas?
>>>
>>>
>>> Flavio
>>>
>>> --- On Sun, 9/19/10, Mark Klein <>
>> wrote:
>>>
>>>> From: Mark Klein <>
>>>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
>> File
>>>> To: "For discussion and help for and by the users
>> of the libRETS C+
>>>> + library"
>>>> Date: Sunday, September 19, 2010, 3:40 PM
>>>> On Sep 19, 2010, at 1:31 PM, Flavio
>>>> Smirne wrote:
>>>>
>>>>> I'm ready to send a request. Do you want me to
>> request
>>>> for a
>>>>> specific LN?
>>>>
>>>>
>>>> Try query "(ListPrice=0+)". There are only 5
>> records to
>>>> worry about.
>>>>
>>>>
>>>>> Meanwhile, I will log in and see what I can
>> find from
>>>> your server...
>>>>>
>>>>> Flavio
>>>>>
>>>>> --- On Sun, 9/19/10, Mark Klein <>
>>>> wrote:
>>>>>
>>>>>> From: Mark Klein <>
>>>>>> Subject: Re: [libRETS-users] [ezRETS-logs]
>> New Log
>>>> File
>>>>>> To: "For discussion and help for and by
>> the users
>>>> of the libRETS C+
>>>>>> + library"
>>>>>> Date: Sunday, September 19, 2010, 3:02 PM
>>>>>> On Sep 19, 2010, at 12:15 PM, Flavio
>>>>>> Smirne wrote:
>>>>>>
>>>>>>> One question I have is why is the
>> server
>>>> sending
>>>>>> windows line
>>>>>>> endings in the first place? They
>> should be
>>>> sending
>>>>>> "\n" only as
>>>>>>> pretty much everyone understands that.
>> It
>>>> seems that
>>>>>> they are
>>>>>>> sending "\n" but are trying to send an
>> extra
>>>> windows
>>>>>> line ending "\r
>>>>>>> \n" for some reason.
>>>>>>
>>>>>>
>>>>>>> The part that bothers me the most is
>> the "0d
>>>> 0d 0a"
>>>>>> line ending you
>>>>>>> are talking about. The extra 0d or "0d
>> 0a"
>>>> doesn't
>>>>>> look right at
>>>>>>> all. Whatever is the reason they are
>> doing
>>>> that, I
>>>>>> don't think the
>>>>>>> extra line ending should be there.
>>>>>>
>>>>>> I agree ... that's part of the problem.
>> Depending
>>>> on the
>>>>>> context, the
>>>>>> various standards (including the RETS
>> standard)
>>>> call for
>>>>>> CR/LF line
>>>>>> termination (also see RFC2616, RFC2045
>> and
>>>> friends) ...
>>>>>> it's that
>>>>>> extra CR causing issues. Note that the
>> normal
>>>> line
>>>>>> termination on Unix
>>>>>> is LF - on Windows, it's CR. That's why I
>> suspect
>>>> something
>>>>>> Windows-
>>>>>> ish is getting in the way.
>>>>>>
>>>>>>>
>>>>>> In any event, in this portion of the
>> payload, the
>>>> line
>>>>>> termination is
>>>>>> moot, so long as it is accounted for by
>> the
>>>>>> chunked-encoding count.
>>>>>>
>>>>>>> AFAIK, the MRED RETS server runs on a
>> FreeBSD
>>>> box, but
>>>>>> I could be
>>>>>>> wrong.
>>>>>>
>>>>>> I use FreeBSD and am running the Variman
>> RETS
>>>> server here.
>>>>>> Why don't
>>>>>> you try your application pointing at my
>> server and
>>>> see what
>>>>>> you get? http://www.dis.com:6103/rets/login
>>>>>> . User: Joe Password: Schmoe. If that's
>>>> successful, we can
>>>>>> try a
>>>>>> contrived test with my playback tool where
>> I play
>>>> back your
>>>>>> log to
>>>>>> you ... that might give a clue as to
>> what's adding
>>>> the
>>>>>> extra CR.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. Setting the version didn't help as expected...
I will wait for an answer from MRED and once I find a solution, I will post it back here so the next person doesn't run into the same problem :)

Thanks for helping me track this down!

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 7:20 PM
> On Sep 19, 2010, at 3:07 PM, Flavio
> Smirne wrote:
>
> > Awesome! After setting the version and getting rid of
> the double 
> > encoding, everything worked fine.
> >
> > I wonder if the original problem wasn't related to me
> not setting 
> > the version... I will try playing with that as
> well...
>
> I don't see how the version differences would cause the
> server to send 
> invalid chunked-encoded data. Nevertheless, it's worth a
> try.
>
> >
> > I'm sending the log to you at librets-logs (at)
> crt.realtors.org
>
> I was concerned that your system was the one adding the
> extra CR .. 
> it's not. The log you sent me this last time was formatted
> exactly as 
> I would expect. It is supposed to be the raw data seen by
> libCURL 
> (which we use to abstract away all the html goo) and since
> this log is 
> exactly what I expected, I'm convinced it is the server
> side adding 
> the extra characters and not accounting for them.
>
>
> >
> > Flavio
> >
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 4:54 PM
> >> On Sep 19, 2010, at 2:24 PM, Flavio
> >> Smirne wrote:
> >>
> >>> .NET query (librets)
> >>>
> >>>
> >>
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
> >>
> >>>
> >>
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
> >>>
> >>> Answer:
> >>>
> >>> > ReplyText="Miscellaneous
> >> Search Error:
> >>> Invalid query type: DMQL"/>
> >>
> >> You're not setting the RETS version on the client
> side, so
> >> it is
> >> defaulting to 1.0. On the server side, Variman no
> longer
> >> supports RETS
> >> 1.0, hence the error.
> >>
> >>> The 2 queries look exactly the same to me,
> except for
> >> the
> >>> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
> >>
> >> Are you doing any encoding or just letting libRETS
> handle
> >> it? This
> >> almost looks like it's double encoded.
> >>
> >>>
> >>> Any ideas?
> >>>
> >>>
> >>> Flavio
> >>>
> >>> --- On Sun, 9/19/10, Mark Klein <>
> >> wrote:
> >>>
> >>>> From: Mark Klein <>
> >>>> Subject: Re: [libRETS-users] [ezRETS-logs]
> New Log
> >> File
> >>>> To: "For discussion and help for and by
> the users
> >> of the libRETS C+
> >>>> + library"
> >>>> Date: Sunday, September 19, 2010, 3:40 PM
> >>>> On Sep 19, 2010, at 1:31 PM, Flavio
> >>>> Smirne wrote:
> >>>>
> >>>>> I'm ready to send a request. Do you
> want me to
> >> request
> >>>> for a
> >>>>> specific LN?
> >>>>
> >>>>
> >>>> Try query "(ListPrice=0+)". There are only
> 5
> >> records to
> >>>> worry about.
> >>>>
> >>>>
> >>>>> Meanwhile, I will log in and see what
> I can
> >> find from
> >>>> your server...
> >>>>>
> >>>>> Flavio
> >>>>>
> >>>>> --- On Sun, 9/19/10, Mark Klein <>
> >>>> wrote:
> >>>>>
> >>>>>> From: Mark Klein <>
> >>>>>> Subject: Re: [libRETS-users]
> [ezRETS-logs]
> >> New Log
> >>>> File
> >>>>>> To: "For discussion and help for
> and by
> >> the users
> >>>> of the libRETS C+
> >>>>>> + library"
> >>>>>> Date: Sunday, September 19, 2010,
> 3:02 PM
> >>>>>> On Sep 19, 2010, at 12:15 PM,
> Flavio
> >>>>>> Smirne wrote:
> >>>>>>
> >>>>>>> One question I have is why is
> the
> >> server
> >>>> sending
> >>>>>> windows line
> >>>>>>> endings in the first place?
> They
> >> should be
> >>>> sending
> >>>>>> "\n" only as
> >>>>>>> pretty much everyone
> understands that.
> >> It
> >>>> seems that
> >>>>>> they are
> >>>>>>> sending "\n" but are trying to
> send an
> >> extra
> >>>> windows
> >>>>>> line ending "\r
> >>>>>>> \n" for some reason.
> >>>>>>
> >>>>>>
> >>>>>>> The part that bothers me the
> most is
> >> the "0d
> >>>> 0d 0a"
> >>>>>> line ending you
> >>>>>>> are talking about. The extra
> 0d or "0d
> >> 0a"
> >>>> doesn't
> >>>>>> look right at
> >>>>>>> all. Whatever is the reason
> they are
> >> doing
> >>>> that, I
> >>>>>> don't think the
> >>>>>>> extra line ending should be
> there.
> >>>>>>
> >>>>>> I agree ... that's part of the
> problem.
> >> Depending
> >>>> on the
> >>>>>> context, the
> >>>>>> various standards (including the
> RETS
> >> standard)
> >>>> call for
> >>>>>> CR/LF line
> >>>>>> termination (also see RFC2616,
> RFC2045
> >> and
> >>>> friends) ...
> >>>>>> it's that
> >>>>>> extra CR causing issues. Note that
> the
> >> normal
> >>>> line
> >>>>>> termination on Unix
> >>>>>> is LF - on Windows, it's CR.
> That's why I
> >> suspect
> >>>> something
> >>>>>> Windows-
> >>>>>> ish is getting in the way.
> >>>>>>
> >>>>>>>
> >>>>>> In any event, in this portion of
> the
> >> payload, the
> >>>> line
> >>>>>> termination is
> >>>>>> moot, so long as it is accounted
> for by
> >> the
> >>>>>> chunked-encoding count.
> >>>>>>
> >>>>>>> AFAIK, the MRED RETS server
> runs on a
> >> FreeBSD
> >>>> box, but
> >>>>>> I could be
> >>>>>>> wrong.
> >>>>>>
> >>>>>> I use FreeBSD and am running the
> Variman
> >> RETS
> >>>> server here.
> >>>>>> Why don't
> >>>>>> you try your application pointing
> at my
> >> server and
> >>>> see what
> >>>>>> you get? http://www.dis.com:6103/rets/login
> >>>>>> . User: Joe Password: Schmoe. If
> that's
> >>>> successful, we can
> >>>>>> try a
> >>>>>> contrived test with my playback
> tool where
> >> I play
> >>>> back your
> >>>>>> log to
> >>>>>> you ... that might give a clue as
> to
> >> what's adding
> >>>> the
> >>>>>> extra CR.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe.

In the past I've had to deal a lot with line ending problems. I used to work for a software company where their main product was a cross platform (windows, mac, linux) application.

The part that bothers me the most is the "0d 0d 0a" line ending you are talking about. The extra 0d or "0d 0a" doesn't look right at all. Whatever is the reason they are doing that, I don't think the extra line ending should be there.

To answer your question though, I'm not using any proxy between me and the RETS server. I'm testing this from home with a direct connection from me to Comcast to RETS server.

One question I have is why is the server sending windows line endings in the first place? They should be sending "\n" only as pretty much everyone understands that. It seems that they are sending "\n" but are trying to send an extra windows line ending "\r\n" for some reason. I wonder if it sees that the request is coming from a windows box and tries to conform.

AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be wrong.

Anyway, Thank again for your help. I will forward this again to the MRED people and see what they say.

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:13 AM
>
> On Sep 18, 2010, at 8:09 PM, Flavio Smirne wrote:
>
> > Here's a fresh file. From what I can see, it's exactly
> the same as the other file I sent you (unfortunately).
>
> Yes ... same results.
>
> > If you have any ides, let me know. I will send an
> email when I hear back from my vendor (MRED Chicago).
>
> Without knowing exactly how they're constructing the packet
> length, it's hard to say. Here's the extract from the log
> using a hex editor to avoid changing anything:
>
>
>
>
> The 72c at the beginning of the ASCII portion is the
> length. The way chunked encoding works is that the length is
> embedded in the text in ASCII, but it represents a hex value
> of the length. So, 0x72c is the length of data before the
> next length field. The data is terminated by a length field
> containing 0.
>
> I see that line termination is kinda screwey here and that
> could be part of what's going on ... notice the 0d 0d 0a in
> the hex portion after the characters representing the
> length? There is an extra carriage return. This is a
> "Windows-ism" in that CR is used there for line termination.
> The MIME protocol happens to call for CR/LF line termination
> characters. But, so long as the addtional CR it is accounted
> for properly in the length, that shouldn't matter.
>
> Nevertheless, I should expect to see the next length field
> at offset 72c + 6 (to account for the 0d 0d 0a and the
> "72c"). Here's the section surrounding that target offset:
>
>
>
>
> We'd expect the terminating length at 732. In fact, we find
> it at 73c, or 0x0a additional characters into the data
> stream. And, in my playback tool, that's exactly what I
> needed to adjust the length by in order to get the packet
> interpreted properly.
>
> That brings up one more question: are you using a proxy
> server between yourself and the RETS server? If so, could it
> be mucking with the line termination characters? Something
> "Windows-ish" is getting in the way and as I look at this
> today, I see that the 10 (0x0a) additional characters
> exactly matches the # of additional CR characters in the
> RETS response. That's pretty suspicious. :-)
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 12:15 PM, Flavio Smirne wrote:

> One question I have is why is the server sending windows line
> endings in the first place? They should be sending "\n" only as
> pretty much everyone understands that. It seems that they are
> sending "\n" but are trying to send an extra windows line ending "\r
> \n" for some reason.


> The part that bothers me the most is the "0d 0d 0a" line ending you
> are talking about. The extra 0d or "0d 0a" doesn't look right at
> all. Whatever is the reason they are doing that, I don't think the
> extra line ending should be there.

I agree ... that's part of the problem. Depending on the context, the
various standards (including the RETS standard) call for CR/LF line
termination (also see RFC2616, RFC2045 and friends) ... it's that
extra CR causing issues. Note that the normal line termination on Unix
is LF - on Windows, it's CR. That's why I suspect something Windows-
ish is getting in the way.

>
In any event, in this portion of the payload, the line termination is
moot, so long as it is accounted for by the chunked-encoding count.

> AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be
> wrong.

I use FreeBSD and am running the Variman RETS server here. Why don't
you try your application pointing at my server and see what you get? http://www.dis.com:6103/rets/login
. User: Joe Password: Schmoe. If that's successful, we can try a
contrived test with my playback tool where I play back your log to
you ... that might give a clue as to what's adding the extra CR.




_______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. I'm ready to send a request. Do you want me to request for a specific LN?
Meanwhile, I will log in and see what I can find from your server...

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:02 PM
> On Sep 19, 2010, at 12:15 PM, Flavio
> Smirne wrote:
>
> > One question I have is why is the server sending
> windows line 
> > endings in the first place? They should be sending
> "\n" only as 
> > pretty much everyone understands that. It seems that
> they are 
> > sending "\n" but are trying to send an extra windows
> line ending "\r
> > \n" for some reason.
>
>
> > The part that bothers me the most is the "0d 0d 0a"
> line ending you 
> > are talking about. The extra 0d or "0d 0a" doesn't
> look right at 
> > all. Whatever is the reason they are doing that, I
> don't think the 
> > extra line ending should be there.
>
> I agree ... that's part of the problem. Depending on the
> context, the 
> various standards (including the RETS standard) call for
> CR/LF line 
> termination (also see RFC2616, RFC2045 and friends) ...
> it's that 
> extra CR causing issues. Note that the normal line
> termination on Unix 
> is LF - on Windows, it's CR. That's why I suspect something
> Windows-
> ish is getting in the way.
>
> >
> In any event, in this portion of the payload, the line
> termination is 
> moot, so long as it is accounted for by the
> chunked-encoding count.
>
> > AFAIK, the MRED RETS server runs on a FreeBSD box, but
> I could be 
> > wrong.
>
> I use FreeBSD and am running the Variman RETS server here.
> Why don't 
> you try your application pointing at my server and see what
> you get? http://www.dis.com:6103/rets/login
> . User: Joe Password: Schmoe. If that's successful, we can
> try a 
> contrived test with my playback tool where I play back your
> log to 
> you ... that might give a clue as to what's adding the
> extra CR.
>
>
>
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 1:31 PM, Flavio Smirne wrote:

> I'm ready to send a request. Do you want me to request for a
> specific LN?


Try query "(ListPrice=0+)". There are only 5 records to worry about.


> Meanwhile, I will log in and see what I can find from your server...
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:02 PM
>> On Sep 19, 2010, at 12:15 PM, Flavio
>> Smirne wrote:
>>
>>> One question I have is why is the server sending
>> windows line
>>> endings in the first place? They should be sending
>> "\n" only as
>>> pretty much everyone understands that. It seems that
>> they are
>>> sending "\n" but are trying to send an extra windows
>> line ending "\r
>>> \n" for some reason.
>>
>>
>>> The part that bothers me the most is the "0d 0d 0a"
>> line ending you
>>> are talking about. The extra 0d or "0d 0a" doesn't
>> look right at
>>> all. Whatever is the reason they are doing that, I
>> don't think the
>>> extra line ending should be there.
>>
>> I agree ... that's part of the problem. Depending on the
>> context, the
>> various standards (including the RETS standard) call for
>> CR/LF line
>> termination (also see RFC2616, RFC2045 and friends) ...
>> it's that
>> extra CR causing issues. Note that the normal line
>> termination on Unix
>> is LF - on Windows, it's CR. That's why I suspect something
>> Windows-
>> ish is getting in the way.
>>
>>>
>> In any event, in this portion of the payload, the line
>> termination is
>> moot, so long as it is accounted for by the
>> chunked-encoding count.
>>
>>> AFAIK, the MRED RETS server runs on a FreeBSD box, but
>> I could be
>>> wrong.
>>
>> I use FreeBSD and am running the Variman RETS server here.
>> Why don't
>> you try your application pointing at my server and see what
>> you get? http://www.dis.com:6103/rets/login
>> . User: Joe Password: Schmoe. If that's successful, we can
>> try a
>> contrived test with my playback tool where I play back your
>> log to
>> you ... that might give a clue as to what's adding the
>> extra CR.
>>
>>
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. After playing with the settings, I'm able to retrieve the 5 records with Firefox, but I'm unable to retrieve the records using librets on my .net app.

Here are the details:

Firefox Query:

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=%28ListPrice=0%2B%29&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:





......more data......




.NET query (librets)

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice%3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:



The 2 queries look exactly the same to me, except for the %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Any ideas?


Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:40 PM
> On Sep 19, 2010, at 1:31 PM, Flavio
> Smirne wrote:
>
> > I'm ready to send a request. Do you want me to request
> for a 
> > specific LN?
>
>
> Try query "(ListPrice=0+)". There are only 5 records to
> worry about.
>
>
> > Meanwhile, I will log in and see what I can find from
> your server...
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:02 PM
> >> On Sep 19, 2010, at 12:15 PM, Flavio
> >> Smirne wrote:
> >>
> >>> One question I have is why is the server
> sending
> >> windows line
> >>> endings in the first place? They should be
> sending
> >> "\n" only as
> >>> pretty much everyone understands that. It
> seems that
> >> they are
> >>> sending "\n" but are trying to send an extra
> windows
> >> line ending "\r
> >>> \n" for some reason.
> >>
> >>
> >>> The part that bothers me the most is the "0d
> 0d 0a"
> >> line ending you
> >>> are talking about. The extra 0d or "0d 0a"
> doesn't
> >> look right at
> >>> all. Whatever is the reason they are doing
> that, I
> >> don't think the
> >>> extra line ending should be there.
> >>
> >> I agree ... that's part of the problem. Depending
> on the
> >> context, the
> >> various standards (including the RETS standard)
> call for
> >> CR/LF line
> >> termination (also see RFC2616, RFC2045 and
> friends) ...
> >> it's that
> >> extra CR causing issues. Note that the normal
> line
> >> termination on Unix
> >> is LF - on Windows, it's CR. That's why I suspect
> something
> >> Windows-
> >> ish is getting in the way.
> >>
> >>>
> >> In any event, in this portion of the payload, the
> line
> >> termination is
> >> moot, so long as it is accounted for by the
> >> chunked-encoding count.
> >>
> >>> AFAIK, the MRED RETS server runs on a FreeBSD
> box, but
> >> I could be
> >>> wrong.
> >>
> >> I use FreeBSD and am running the Variman RETS
> server here.
> >> Why don't
> >> you try your application pointing at my server and
> see what
> >> you get? http://www.dis.com:6103/rets/login
> >> . User: Joe Password: Schmoe. If that's
> successful, we can
> >> try a
> >> contrived test with my playback tool where I play
> back your
> >> log to
> >> you ... that might give a clue as to what's adding
> the
> >> extra CR.
> >>
> >>
> >>
> >>
> >> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 2:24 PM, Flavio Smirne wrote:

> .NET query (librets)
>
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
>
> Answer:
>
>

You're not setting the RETS version on the client side, so it is
defaulting to 1.0. On the server side, Variman no longer supports RETS
1.0, hence the error.

> The 2 queries look exactly the same to me, except for the
> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Are you doing any encoding or just letting libRETS handle it? This
almost looks like it's double encoded.

>
> Any ideas?
>
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:40 PM
>> On Sep 19, 2010, at 1:31 PM, Flavio
>> Smirne wrote:
>>
>>> I'm ready to send a request. Do you want me to request
>> for a
>>> specific LN?
>>
>>
>> Try query "(ListPrice=0+)". There are only 5 records to
>> worry about.
>>
>>
>>> Meanwhile, I will log in and see what I can find from
>> your server...
>>>
>>> Flavio
>>>
>>> --- On Sun, 9/19/10, Mark Klein <>
>> wrote:
>>>
>>>> From: Mark Klein <>
>>>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
>> File
>>>> To: "For discussion and help for and by the users
>> of the libRETS C+
>>>> + library"
>>>> Date: Sunday, September 19, 2010, 3:02 PM
>>>> On Sep 19, 2010, at 12:15 PM, Flavio
>>>> Smirne wrote:
>>>>
>>>>> One question I have is why is the server
>> sending
>>>> windows line
>>>>> endings in the first place? They should be
>> sending
>>>> "\n" only as
>>>>> pretty much everyone understands that. It
>> seems that
>>>> they are
>>>>> sending "\n" but are trying to send an extra
>> windows
>>>> line ending "\r
>>>>> \n" for some reason.
>>>>
>>>>
>>>>> The part that bothers me the most is the "0d
>> 0d 0a"
>>>> line ending you
>>>>> are talking about. The extra 0d or "0d 0a"
>> doesn't
>>>> look right at
>>>>> all. Whatever is the reason they are doing
>> that, I
>>>> don't think the
>>>>> extra line ending should be there.
>>>>
>>>> I agree ... that's part of the problem. Depending
>> on the
>>>> context, the
>>>> various standards (including the RETS standard)
>> call for
>>>> CR/LF line
>>>> termination (also see RFC2616, RFC2045 and
>> friends) ...
>>>> it's that
>>>> extra CR causing issues. Note that the normal
>> line
>>>> termination on Unix
>>>> is LF - on Windows, it's CR. That's why I suspect
>> something
>>>> Windows-
>>>> ish is getting in the way.
>>>>
>>>>>
>>>> In any event, in this portion of the payload, the
>> line
>>>> termination is
>>>> moot, so long as it is accounted for by the
>>>> chunked-encoding count.
>>>>
>>>>> AFAIK, the MRED RETS server runs on a FreeBSD
>> box, but
>>>> I could be
>>>>> wrong.
>>>>
>>>> I use FreeBSD and am running the Variman RETS
>> server here.
>>>> Why don't
>>>> you try your application pointing at my server and
>> see what
>>>> you get? http://www.dis.com:6103/rets/login
>>>> . User: Joe Password: Schmoe. If that's
>> successful, we can
>>>> try a
>>>> contrived test with my playback tool where I play
>> back your
>>>> log to
>>>> you ... that might give a clue as to what's adding
>> the
>>>> extra CR.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. Awesome! After setting the version and getting rid of the double encoding, everything worked fine.

I wonder if the original problem wasn't related to me not setting the version... I will try playing with that as well...

I'm sending the log to you at librets-logs (at) crt.realtors.org

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 4:54 PM
> On Sep 19, 2010, at 2:24 PM, Flavio
> Smirne wrote:
>
> > .NET query (librets)
> >
> >
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
>
> >
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
> >
> > Answer:
> >
> >
>
> You're not setting the RETS version on the client side, so
> it is 
> defaulting to 1.0. On the server side, Variman no longer
> supports RETS 
> 1.0, hence the error.
>
> > The 2 queries look exactly the same to me, except for
> the 
> > %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
>
> Are you doing any encoding or just letting libRETS handle
> it? This 
> almost looks like it's double encoded.
>
> >
> > Any ideas?
> >
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:40 PM
> >> On Sep 19, 2010, at 1:31 PM, Flavio
> >> Smirne wrote:
> >>
> >>> I'm ready to send a request. Do you want me to
> request
> >> for a
> >>> specific LN?
> >>
> >>
> >> Try query "(ListPrice=0+)". There are only 5
> records to
> >> worry about.
> >>
> >>
> >>> Meanwhile, I will log in and see what I can
> find from
> >> your server...
> >>>
> >>> Flavio
> >>>
> >>> --- On Sun, 9/19/10, Mark Klein <>
> >> wrote:
> >>>
> >>>> From: Mark Klein <>
> >>>> Subject: Re: [libRETS-users] [ezRETS-logs]
> New Log
> >> File
> >>>> To: "For discussion and help for and by
> the users
> >> of the libRETS C+
> >>>> + library"
> >>>> Date: Sunday, September 19, 2010, 3:02 PM
> >>>> On Sep 19, 2010, at 12:15 PM, Flavio
> >>>> Smirne wrote:
> >>>>
> >>>>> One question I have is why is the
> server
> >> sending
> >>>> windows line
> >>>>> endings in the first place? They
> should be
> >> sending
> >>>> "\n" only as
> >>>>> pretty much everyone understands that.
> It
> >> seems that
> >>>> they are
> >>>>> sending "\n" but are trying to send an
> extra
> >> windows
> >>>> line ending "\r
> >>>>> \n" for some reason.
> >>>>
> >>>>
> >>>>> The part that bothers me the most is
> the "0d
> >> 0d 0a"
> >>>> line ending you
> >>>>> are talking about. The extra 0d or "0d
> 0a"
> >> doesn't
> >>>> look right at
> >>>>> all. Whatever is the reason they are
> doing
> >> that, I
> >>>> don't think the
> >>>>> extra line ending should be there.
> >>>>
> >>>> I agree ... that's part of the problem.
> Depending
> >> on the
> >>>> context, the
> >>>> various standards (including the RETS
> standard)
> >> call for
> >>>> CR/LF line
> >>>> termination (also see RFC2616, RFC2045
> and
> >> friends) ...
> >>>> it's that
> >>>> extra CR causing issues. Note that the
> normal
> >> line
> >>>> termination on Unix
> >>>> is LF - on Windows, it's CR. That's why I
> suspect
> >> something
> >>>> Windows-
> >>>> ish is getting in the way.
> >>>>
> >>>>>
> >>>> In any event, in this portion of the
> payload, the
> >> line
> >>>> termination is
> >>>> moot, so long as it is accounted for by
> the
> >>>> chunked-encoding count.
> >>>>
> >>>>> AFAIK, the MRED RETS server runs on a
> FreeBSD
> >> box, but
> >>>> I could be
> >>>>> wrong.
> >>>>
> >>>> I use FreeBSD and am running the Variman
> RETS
> >> server here.
> >>>> Why don't
> >>>> you try your application pointing at my
> server and
> >> see what
> >>>> you get? http://www.dis.com:6103/rets/login
> >>>> . User: Joe Password: Schmoe. If that's
> >> successful, we can
> >>>> try a
> >>>> contrived test with my playback tool where
> I play
> >> back your
> >>>> log to
> >>>> you ... that might give a clue as to
> what's adding
> >> the
> >>>> extra CR.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 3:07 PM, Flavio Smirne wrote:

> Awesome! After setting the version and getting rid of the double
> encoding, everything worked fine.
>
> I wonder if the original problem wasn't related to me not setting
> the version... I will try playing with that as well...

I don't see how the version differences would cause the server to send
invalid chunked-encoded data. Nevertheless, it's worth a try.

>
> I'm sending the log to you at librets-logs (at) crt.realtors.org

I was concerned that your system was the one adding the extra CR ..
it's not. The log you sent me this last time was formatted exactly as
I would expect. It is supposed to be the raw data seen by libCURL
(which we use to abstract away all the html goo) and since this log is
exactly what I expected, I'm convinced it is the server side adding
the extra characters and not accounting for them.


>
> Flavio
>
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 4:54 PM
>> On Sep 19, 2010, at 2:24 PM, Flavio
>> Smirne wrote:
>>
>>> .NET query (librets)
>>>
>>>
>> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
>>
>>>
>> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
>>>
>>> Answer:
>>>
>>>
>>
>> You're not setting the RETS version on the client side, so
>> it is
>> defaulting to 1.0. On the server side, Variman no longer
>> supports RETS
>> 1.0, hence the error.
>>
>>> The 2 queries look exactly the same to me, except for
>> the
>>> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
>>
>> Are you doing any encoding or just letting libRETS handle
>> it? This
>> almost looks like it's double encoded.
>>
>>>
>>> Any ideas?
>>>
>>>
>>> Flavio
>>>
>>> --- On Sun, 9/19/10, Mark Klein <>
>> wrote:
>>>
>>>> From: Mark Klein <>
>>>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
>> File
>>>> To: "For discussion and help for and by the users
>> of the libRETS C+
>>>> + library"
>>>> Date: Sunday, September 19, 2010, 3:40 PM
>>>> On Sep 19, 2010, at 1:31 PM, Flavio
>>>> Smirne wrote:
>>>>
>>>>> I'm ready to send a request. Do you want me to
>> request
>>>> for a
>>>>> specific LN?
>>>>
>>>>
>>>> Try query "(ListPrice=0+)". There are only 5
>> records to
>>>> worry about.
>>>>
>>>>
>>>>> Meanwhile, I will log in and see what I can
>> find from
>>>> your server...
>>>>>
>>>>> Flavio
>>>>>
>>>>> --- On Sun, 9/19/10, Mark Klein <>
>>>> wrote:
>>>>>
>>>>>> From: Mark Klein <>
>>>>>> Subject: Re: [libRETS-users] [ezRETS-logs]
>> New Log
>>>> File
>>>>>> To: "For discussion and help for and by
>> the users
>>>> of the libRETS C+
>>>>>> + library"
>>>>>> Date: Sunday, September 19, 2010, 3:02 PM
>>>>>> On Sep 19, 2010, at 12:15 PM, Flavio
>>>>>> Smirne wrote:
>>>>>>
>>>>>>> One question I have is why is the
>> server
>>>> sending
>>>>>> windows line
>>>>>>> endings in the first place? They
>> should be
>>>> sending
>>>>>> "\n" only as
>>>>>>> pretty much everyone understands that.
>> It
>>>> seems that
>>>>>> they are
>>>>>>> sending "\n" but are trying to send an
>> extra
>>>> windows
>>>>>> line ending "\r
>>>>>>> \n" for some reason.
>>>>>>
>>>>>>
>>>>>>> The part that bothers me the most is
>> the "0d
>>>> 0d 0a"
>>>>>> line ending you
>>>>>>> are talking about. The extra 0d or "0d
>> 0a"
>>>> doesn't
>>>>>> look right at
>>>>>>> all. Whatever is the reason they are
>> doing
>>>> that, I
>>>>>> don't think the
>>>>>>> extra line ending should be there.
>>>>>>
>>>>>> I agree ... that's part of the problem.
>> Depending
>>>> on the
>>>>>> context, the
>>>>>> various standards (including the RETS
>> standard)
>>>> call for
>>>>>> CR/LF line
>>>>>> termination (also see RFC2616, RFC2045
>> and
>>>> friends) ...
>>>>>> it's that
>>>>>> extra CR causing issues. Note that the
>> normal
>>>> line
>>>>>> termination on Unix
>>>>>> is LF - on Windows, it's CR. That's why I
>> suspect
>>>> something
>>>>>> Windows-
>>>>>> ish is getting in the way.
>>>>>>
>>>>>>>
>>>>>> In any event, in this portion of the
>> payload, the
>>>> line
>>>>>> termination is
>>>>>> moot, so long as it is accounted for by
>> the
>>>>>> chunked-encoding count.
>>>>>>
>>>>>>> AFAIK, the MRED RETS server runs on a
>> FreeBSD
>>>> box, but
>>>>>> I could be
>>>>>>> wrong.
>>>>>>
>>>>>> I use FreeBSD and am running the Variman
>> RETS
>>>> server here.
>>>>>> Why don't
>>>>>> you try your application pointing at my
>> server and
>>>> see what
>>>>>> you get? http://www.dis.com:6103/rets/login
>>>>>> . User: Joe Password: Schmoe. If that's
>>>> successful, we can
>>>>>> try a
>>>>>> contrived test with my playback tool where
>> I play
>>>> back your
>>>>>> log to
>>>>>> you ... that might give a clue as to
>> what's adding
>>>> the
>>>>>> extra CR.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. Setting the version didn't help as expected...
I will wait for an answer from MRED and once I find a solution, I will post it back here so the next person doesn't run into the same problem :)

Thanks for helping me track this down!

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 7:20 PM
> On Sep 19, 2010, at 3:07 PM, Flavio
> Smirne wrote:
>
> > Awesome! After setting the version and getting rid of
> the double 
> > encoding, everything worked fine.
> >
> > I wonder if the original problem wasn't related to me
> not setting 
> > the version... I will try playing with that as
> well...
>
> I don't see how the version differences would cause the
> server to send 
> invalid chunked-encoded data. Nevertheless, it's worth a
> try.
>
> >
> > I'm sending the log to you at librets-logs (at)
> crt.realtors.org
>
> I was concerned that your system was the one adding the
> extra CR .. 
> it's not. The log you sent me this last time was formatted
> exactly as 
> I would expect. It is supposed to be the raw data seen by
> libCURL 
> (which we use to abstract away all the html goo) and since
> this log is 
> exactly what I expected, I'm convinced it is the server
> side adding 
> the extra characters and not accounting for them.
>
>
> >
> > Flavio
> >
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 4:54 PM
> >> On Sep 19, 2010, at 2:24 PM, Flavio
> >> Smirne wrote:
> >>
> >>> .NET query (librets)
> >>>
> >>>
> >>
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
> >>
> >>>
> >>
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
> >>>
> >>> Answer:
> >>>
> >>> > ReplyText="Miscellaneous
> >> Search Error:
> >>> Invalid query type: DMQL"/>
> >>
> >> You're not setting the RETS version on the client
> side, so
> >> it is
> >> defaulting to 1.0. On the server side, Variman no
> longer
> >> supports RETS
> >> 1.0, hence the error.
> >>
> >>> The 2 queries look exactly the same to me,
> except for
> >> the
> >>> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
> >>
> >> Are you doing any encoding or just letting libRETS
> handle
> >> it? This
> >> almost looks like it's double encoded.
> >>
> >>>
> >>> Any ideas?
> >>>
> >>>
> >>> Flavio
> >>>
> >>> --- On Sun, 9/19/10, Mark Klein <>
> >> wrote:
> >>>
> >>>> From: Mark Klein <>
> >>>> Subject: Re: [libRETS-users] [ezRETS-logs]
> New Log
> >> File
> >>>> To: "For discussion and help for and by
> the users
> >> of the libRETS C+
> >>>> + library"
> >>>> Date: Sunday, September 19, 2010, 3:40 PM
> >>>> On Sep 19, 2010, at 1:31 PM, Flavio
> >>>> Smirne wrote:
> >>>>
> >>>>> I'm ready to send a request. Do you
> want me to
> >> request
> >>>> for a
> >>>>> specific LN?
> >>>>
> >>>>
> >>>> Try query "(ListPrice=0+)". There are only
> 5
> >> records to
> >>>> worry about.
> >>>>
> >>>>
> >>>>> Meanwhile, I will log in and see what
> I can
> >> find from
> >>>> your server...
> >>>>>
> >>>>> Flavio
> >>>>>
> >>>>> --- On Sun, 9/19/10, Mark Klein <>
> >>>> wrote:
> >>>>>
> >>>>>> From: Mark Klein <>
> >>>>>> Subject: Re: [libRETS-users]
> [ezRETS-logs]
> >> New Log
> >>>> File
> >>>>>> To: "For discussion and help for
> and by
> >> the users
> >>>> of the libRETS C+
> >>>>>> + library"
> >>>>>> Date: Sunday, September 19, 2010,
> 3:02 PM
> >>>>>> On Sep 19, 2010, at 12:15 PM,
> Flavio
> >>>>>> Smirne wrote:
> >>>>>>
> >>>>>>> One question I have is why is
> the
> >> server
> >>>> sending
> >>>>>> windows line
> >>>>>>> endings in the first place?
> They
> >> should be
> >>>> sending
> >>>>>> "\n" only as
> >>>>>>> pretty much everyone
> understands that.
> >> It
> >>>> seems that
> >>>>>> they are
> >>>>>>> sending "\n" but are trying to
> send an
> >> extra
> >>>> windows
> >>>>>> line ending "\r
> >>>>>>> \n" for some reason.
> >>>>>>
> >>>>>>
> >>>>>>> The part that bothers me the
> most is
> >> the "0d
> >>>> 0d 0a"
> >>>>>> line ending you
> >>>>>>> are talking about. The extra
> 0d or "0d
> >> 0a"
> >>>> doesn't
> >>>>>> look right at
> >>>>>>> all. Whatever is the reason
> they are
> >> doing
> >>>> that, I
> >>>>>> don't think the
> >>>>>>> extra line ending should be
> there.
> >>>>>>
> >>>>>> I agree ... that's part of the
> problem.
> >> Depending
> >>>> on the
> >>>>>> context, the
> >>>>>> various standards (including the
> RETS
> >> standard)
> >>>> call for
> >>>>>> CR/LF line
> >>>>>> termination (also see RFC2616,
> RFC2045
> >> and
> >>>> friends) ...
> >>>>>> it's that
> >>>>>> extra CR causing issues. Note that
> the
> >> normal
> >>>> line
> >>>>>> termination on Unix
> >>>>>> is LF - on Windows, it's CR.
> That's why I
> >> suspect
> >>>> something
> >>>>>> Windows-
> >>>>>> ish is getting in the way.
> >>>>>>
> >>>>>>>
> >>>>>> In any event, in this portion of
> the
> >> payload, the
> >>>> line
> >>>>>> termination is
> >>>>>> moot, so long as it is accounted
> for by
> >> the
> >>>>>> chunked-encoding count.
> >>>>>>
> >>>>>>> AFAIK, the MRED RETS server
> runs on a
> >> FreeBSD
> >>>> box, but
> >>>>>> I could be
> >>>>>>> wrong.
> >>>>>>
> >>>>>> I use FreeBSD and am running the
> Variman
> >> RETS
> >>>> server here.
> >>>>>> Why don't
> >>>>>> you try your application pointing
> at my
> >> server and
> >>>> see what
> >>>>>> you get? http://www.dis.com:6103/rets/login
> >>>>>> . User: Joe Password: Schmoe. If
> that's
> >>>> successful, we can
> >>>>>> try a
> >>>>>> contrived test with my playback
> tool where
> >> I play
> >>>> back your
> >>>>>> log to
> >>>>>> you ... that might give a clue as
> to
> >> what's adding
> >>>> the
> >>>>>> extra CR.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. Ok. I haven't heard back from the vendor yet, but I came up with 2 workarounds for this problem:

1) Instead of calling RetsSession.Search(request), one could make the following calls:

byte[] foo = Session.SearchAsArray(req);
string test = System.Text.Encoding.UTF8.GetString(foo);

This gives the correct encoded string, but I lose all the parsing functionality of libRETS. Not very good, since I don't want to parse the data myself.

2) Call SearchResultSet results = RetsSession.Search(request) normally, but then do the following to correct the encoding:

string rem = results.GetString("REMARKS");
byte[] decoded = System.Text.Encoding.Default.GetBytes(rem);
correct = System.Text.Encoding.UTF8.GetString(decoded);

This is not an ideal solution, but it does work. I still believe that there's a way to set the correct encoding at some level and get all this done for free, but I wanted to play with this and find a workaround in case the vendor doesn't give me an acceptable solution.

I hope this helps someone...

Thanks,

Flavio

--- On Sun, 9/19/10, Flavio Smirne <> wrote:

> From: Flavio Smirne <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:06 PM
> Setting the version didn't help as
> expected...
> I will wait for an answer from MRED and once I find a
> solution, I will post it back here so the next person
> doesn't run into the same problem :)
>
> Thanks for helping me track this down!
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <>
> wrote:
>
> > From: Mark Klein <>
> > Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> > To: "For discussion and help for and by the users of
> the libRETS C++ library"
> > Date: Sunday, September 19, 2010, 7:20 PM
> > On Sep 19, 2010, at 3:07 PM, Flavio
> > Smirne wrote:
> >
> > > Awesome! After setting the version and getting
> rid of
> > the double 
> > > encoding, everything worked fine.
> > >
> > > I wonder if the original problem wasn't related
> to me
> > not setting 
> > > the version... I will try playing with that as
> > well...
> >
> > I don't see how the version differences would cause
> the
> > server to send 
> > invalid chunked-encoded data. Nevertheless, it's worth
> a
> > try.
> >
> > >
> > > I'm sending the log to you at librets-logs (at)
> > crt.realtors.org
> >
> > I was concerned that your system was the one adding
> the
> > extra CR .. 
> > it's not. The log you sent me this last time was
> formatted
> > exactly as 
> > I would expect. It is supposed to be the raw data seen
> by
> > libCURL 
> > (which we use to abstract away all the html goo) and
> since
> > this log is 
> > exactly what I expected, I'm convinced it is the
> server
> > side adding 
> > the extra characters and not accounting for them.
> >
> >
> > >
> > > Flavio
> > >
> > >
> > > --- On Sun, 9/19/10, Mark Klein <>
> > wrote:
> > >
> > >> From: Mark Klein <>
> > >> Subject: Re: [libRETS-users] [ezRETS-logs]
> New Log
> > File
> > >> To: "For discussion and help for and by the
> users
> > of the libRETS C+
> > >> + library"
> > >> Date: Sunday, September 19, 2010, 4:54 PM
> > >> On Sep 19, 2010, at 2:24 PM, Flavio
> > >> Smirne wrote:
> > >>
> > >>> .NET query (librets)
> > >>>
> > >>>
> > >>
> >
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
> > >>
> > >>>
> > >>
> >
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
> > >>>
> > >>> Answer:
> > >>>
> > >>> > > ReplyText="Miscellaneous
> > >> Search Error:
> > >>> Invalid query type: DMQL"/>
> > >>
> > >> You're not setting the RETS version on the
> client
> > side, so
> > >> it is
> > >> defaulting to 1.0. On the server side,
> Variman no
> > longer
> > >> supports RETS
> > >> 1.0, hence the error.
> > >>
> > >>> The 2 queries look exactly the same to
> me,
> > except for
> > >> the
> > >>> %28ListPrice=0%2B%29 vs
> (ListPrice%3d0%252B).
> > >>
> > >> Are you doing any encoding or just letting
> libRETS
> > handle
> > >> it? This
> > >> almost looks like it's double encoded.
> > >>
> > >>>
> > >>> Any ideas?
> > >>>
> > >>>
> > >>> Flavio
> > >>>
> > >>> --- On Sun, 9/19/10, Mark Klein <>
> > >> wrote:
> > >>>
> > >>>> From: Mark Klein <>
> > >>>> Subject: Re: [libRETS-users]
> [ezRETS-logs]
> > New Log
> > >> File
> > >>>> To: "For discussion and help for and
> by
> > the users
> > >> of the libRETS C+
> > >>>> + library"
> > >>>> Date: Sunday, September 19, 2010,
> 3:40 PM
> > >>>> On Sep 19, 2010, at 1:31 PM, Flavio
> > >>>> Smirne wrote:
> > >>>>
> > >>>>> I'm ready to send a request. Do
> you
> > want me to
> > >> request
> > >>>> for a
> > >>>>> specific LN?
> > >>>>
> > >>>>
> > >>>> Try query "(ListPrice=0+)". There are
> only
> > 5
> > >> records to
> > >>>> worry about.
> > >>>>
> > >>>>
> > >>>>> Meanwhile, I will log in and see
> what
> > I can
> > >> find from
> > >>>> your server...
> > >>>>>
> > >>>>> Flavio
> > >>>>>
> > >>>>> --- On Sun, 9/19/10, Mark Klein
> <>
> > >>>> wrote:
> > >>>>>
> > >>>>>> From: Mark Klein <>
> > >>>>>> Subject: Re: [libRETS-users]
> > [ezRETS-logs]
> > >> New Log
> > >>>> File
> > >>>>>> To: "For discussion and help
> for
> > and by
> > >> the users
> > >>>> of the libRETS C+
> > >>>>>> + library"
> > >>>>>> Date: Sunday, September 19,
> 2010,
> > 3:02 PM
> > >>>>>> On Sep 19, 2010, at 12:15
> PM,
> > Flavio
> > >>>>>> Smirne wrote:
> > >>>>>>
> > >>>>>>> One question I have is
> why is
> > the
> > >> server
> > >>>> sending
> > >>>>>> windows line
> > >>>>>>> endings in the first
> place?
> > They
> > >> should be
> > >>>> sending
> > >>>>>> "\n" only as
> > >>>>>>> pretty much everyone
> > understands that.
> > >> It
> > >>>> seems that
> > >>>>>> they are
> > >>>>>>> sending "\n" but are
> trying to
> > send an
> > >> extra
> > >>>> windows
> > >>>>>> line ending "\r
> > >>>>>>> \n" for some reason.
> > >>>>>>
> > >>>>>>
> > >>>>>>> The part that bothers me
> the
> > most is
> > >> the "0d
> > >>>> 0d 0a"
> > >>>>>> line ending you
> > >>>>>>> are talking about. The
> extra
> > 0d or "0d
> > >> 0a"
> > >>>> doesn't
> > >>>>>> look right at
> > >>>>>>> all. Whatever is the
> reason
> > they are
> > >> doing
> > >>>> that, I
> > >>>>>> don't think the
> > >>>>>>> extra line ending should
> be
> > there.
> > >>>>>>
> > >>>>>> I agree ... that's part of
> the
> > problem.
> > >> Depending
> > >>>> on the
> > >>>>>> context, the
> > >>>>>> various standards (including
> the
> > RETS
> > >> standard)
> > >>>> call for
> > >>>>>> CR/LF line
> > >>>>>> termination (also see
> RFC2616,
> > RFC2045
> > >> and
> > >>>> friends) ...
> > >>>>>> it's that
> > >>>>>> extra CR causing issues. Note
> that
> > the
> > >> normal
> > >>>> line
> > >>>>>> termination on Unix
> > >>>>>> is LF - on Windows, it's CR.
> > That's why I
> > >> suspect
> > >>>> something
> > >>>>>> Windows-
> > >>>>>> ish is getting in the way.
> > >>>>>>
> > >>>>>>>
> > >>>>>> In any event, in this portion
> of
> > the
> > >> payload, the
> > >>>> line
> > >>>>>> termination is
> > >>>>>> moot, so long as it is
> accounted
> > for by
> > >> the
> > >>>>>> chunked-encoding count.
> > >>>>>>
> > >>>>>>> AFAIK, the MRED RETS
> server
> > runs on a
> > >> FreeBSD
> > >>>> box, but
> > >>>>>> I could be
> > >>>>>>> wrong.
> > >>>>>>
> > >>>>>> I use FreeBSD and am running
> the
> > Variman
> > >> RETS
> > >>>> server here.
> > >>>>>> Why don't
> > >>>>>> you try your application
> pointing
> > at my
> > >> server and
> > >>>> see what
> > >>>>>> you get? http://www.dis.com:6103/rets/login
> > >>>>>> . User: Joe Password: Schmoe.
> If
> > that's
> > >>>> successful, we can
> > >>>>>> try a
> > >>>>>> contrived test with my
> playback
> > tool where
> > >> I play
> > >>>> back your
> > >>>>>> log to
> > >>>>>> you ... that might give a
> clue as
> > to
> > >> what's adding
> > >>>> the
> > >>>>>> extra CR.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe.

In the past I've had to deal a lot with line ending problems. I used to work for a software company where their main product was a cross platform (windows, mac, linux) application.

The part that bothers me the most is the "0d 0d 0a" line ending you are talking about. The extra 0d or "0d 0a" doesn't look right at all. Whatever is the reason they are doing that, I don't think the extra line ending should be there.

To answer your question though, I'm not using any proxy between me and the RETS server. I'm testing this from home with a direct connection from me to Comcast to RETS server.

One question I have is why is the server sending windows line endings in the first place? They should be sending "\n" only as pretty much everyone understands that. It seems that they are sending "\n" but are trying to send an extra windows line ending "\r\n" for some reason. I wonder if it sees that the request is coming from a windows box and tries to conform.

AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be wrong.

Anyway, Thank again for your help. I will forward this again to the MRED people and see what they say.

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:13 AM
>
> On Sep 18, 2010, at 8:09 PM, Flavio Smirne wrote:
>
> > Here's a fresh file. From what I can see, it's exactly
> the same as the other file I sent you (unfortunately).
>
> Yes ... same results.
>
> > If you have any ides, let me know. I will send an
> email when I hear back from my vendor (MRED Chicago).
>
> Without knowing exactly how they're constructing the packet
> length, it's hard to say. Here's the extract from the log
> using a hex editor to avoid changing anything:
>
>
>
>
> The 72c at the beginning of the ASCII portion is the
> length. The way chunked encoding works is that the length is
> embedded in the text in ASCII, but it represents a hex value
> of the length. So, 0x72c is the length of data before the
> next length field. The data is terminated by a length field
> containing 0.
>
> I see that line termination is kinda screwey here and that
> could be part of what's going on ... notice the 0d 0d 0a in
> the hex portion after the characters representing the
> length? There is an extra carriage return. This is a
> "Windows-ism" in that CR is used there for line termination.
> The MIME protocol happens to call for CR/LF line termination
> characters. But, so long as the addtional CR it is accounted
> for properly in the length, that shouldn't matter.
>
> Nevertheless, I should expect to see the next length field
> at offset 72c + 6 (to account for the 0d 0d 0a and the
> "72c"). Here's the section surrounding that target offset:
>
>
>
>
> We'd expect the terminating length at 732. In fact, we find
> it at 73c, or 0x0a additional characters into the data
> stream. And, in my playback tool, that's exactly what I
> needed to adjust the length by in order to get the packet
> interpreted properly.
>
> That brings up one more question: are you using a proxy
> server between yourself and the RETS server? If so, could it
> be mucking with the line termination characters? Something
> "Windows-ish" is getting in the way and as I look at this
> today, I see that the 10 (0x0a) additional characters
> exactly matches the # of additional CR characters in the
> RETS response. That's pretty suspicious. :-)
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 12:15 PM, Flavio Smirne wrote:

> One question I have is why is the server sending windows line
> endings in the first place? They should be sending "\n" only as
> pretty much everyone understands that. It seems that they are
> sending "\n" but are trying to send an extra windows line ending "\r
> \n" for some reason.


> The part that bothers me the most is the "0d 0d 0a" line ending you
> are talking about. The extra 0d or "0d 0a" doesn't look right at
> all. Whatever is the reason they are doing that, I don't think the
> extra line ending should be there.

I agree ... that's part of the problem. Depending on the context, the
various standards (including the RETS standard) call for CR/LF line
termination (also see RFC2616, RFC2045 and friends) ... it's that
extra CR causing issues. Note that the normal line termination on Unix
is LF - on Windows, it's CR. That's why I suspect something Windows-
ish is getting in the way.

>
In any event, in this portion of the payload, the line termination is
moot, so long as it is accounted for by the chunked-encoding count.

> AFAIK, the MRED RETS server runs on a FreeBSD box, but I could be
> wrong.

I use FreeBSD and am running the Variman RETS server here. Why don't
you try your application pointing at my server and see what you get? http://www.dis.com:6103/rets/login
. User: Joe Password: Schmoe. If that's successful, we can try a
contrived test with my playback tool where I play back your log to
you ... that might give a clue as to what's adding the extra CR.




_______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. I'm ready to send a request. Do you want me to request for a specific LN?
Meanwhile, I will log in and see what I can find from your server...

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:02 PM
> On Sep 19, 2010, at 12:15 PM, Flavio
> Smirne wrote:
>
> > One question I have is why is the server sending
> windows line 
> > endings in the first place? They should be sending
> "\n" only as 
> > pretty much everyone understands that. It seems that
> they are 
> > sending "\n" but are trying to send an extra windows
> line ending "\r
> > \n" for some reason.
>
>
> > The part that bothers me the most is the "0d 0d 0a"
> line ending you 
> > are talking about. The extra 0d or "0d 0a" doesn't
> look right at 
> > all. Whatever is the reason they are doing that, I
> don't think the 
> > extra line ending should be there.
>
> I agree ... that's part of the problem. Depending on the
> context, the 
> various standards (including the RETS standard) call for
> CR/LF line 
> termination (also see RFC2616, RFC2045 and friends) ...
> it's that 
> extra CR causing issues. Note that the normal line
> termination on Unix 
> is LF - on Windows, it's CR. That's why I suspect something
> Windows-
> ish is getting in the way.
>
> >
> In any event, in this portion of the payload, the line
> termination is 
> moot, so long as it is accounted for by the
> chunked-encoding count.
>
> > AFAIK, the MRED RETS server runs on a FreeBSD box, but
> I could be 
> > wrong.
>
> I use FreeBSD and am running the Variman RETS server here.
> Why don't 
> you try your application pointing at my server and see what
> you get? http://www.dis.com:6103/rets/login
> . User: Joe Password: Schmoe. If that's successful, we can
> try a 
> contrived test with my playback tool where I play back your
> log to 
> you ... that might give a clue as to what's adding the
> extra CR.
>
>
>
>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 1:31 PM, Flavio Smirne wrote:

> I'm ready to send a request. Do you want me to request for a
> specific LN?


Try query "(ListPrice=0+)". There are only 5 records to worry about.


> Meanwhile, I will log in and see what I can find from your server...
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:02 PM
>> On Sep 19, 2010, at 12:15 PM, Flavio
>> Smirne wrote:
>>
>>> One question I have is why is the server sending
>> windows line
>>> endings in the first place? They should be sending
>> "\n" only as
>>> pretty much everyone understands that. It seems that
>> they are
>>> sending "\n" but are trying to send an extra windows
>> line ending "\r
>>> \n" for some reason.
>>
>>
>>> The part that bothers me the most is the "0d 0d 0a"
>> line ending you
>>> are talking about. The extra 0d or "0d 0a" doesn't
>> look right at
>>> all. Whatever is the reason they are doing that, I
>> don't think the
>>> extra line ending should be there.
>>
>> I agree ... that's part of the problem. Depending on the
>> context, the
>> various standards (including the RETS standard) call for
>> CR/LF line
>> termination (also see RFC2616, RFC2045 and friends) ...
>> it's that
>> extra CR causing issues. Note that the normal line
>> termination on Unix
>> is LF - on Windows, it's CR. That's why I suspect something
>> Windows-
>> ish is getting in the way.
>>
>>>
>> In any event, in this portion of the payload, the line
>> termination is
>> moot, so long as it is accounted for by the
>> chunked-encoding count.
>>
>>> AFAIK, the MRED RETS server runs on a FreeBSD box, but
>> I could be
>>> wrong.
>>
>> I use FreeBSD and am running the Variman RETS server here.
>> Why don't
>> you try your application pointing at my server and see what
>> you get? http://www.dis.com:6103/rets/login
>> . User: Joe Password: Schmoe. If that's successful, we can
>> try a
>> contrived test with my playback tool where I play back your
>> log to
>> you ... that might give a clue as to what's adding the
>> extra CR.
>>
>>
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. After playing with the settings, I'm able to retrieve the 5 records with Firefox, but I'm unable to retrieve the records using librets on my .net app.

Here are the details:

Firefox Query:

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=%28ListPrice=0%2B%29&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:





......more data......




.NET query (librets)

Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice%3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0

Answer:



The 2 queries look exactly the same to me, except for the %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Any ideas?


Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 3:40 PM
> On Sep 19, 2010, at 1:31 PM, Flavio
> Smirne wrote:
>
> > I'm ready to send a request. Do you want me to request
> for a 
> > specific LN?
>
>
> Try query "(ListPrice=0+)". There are only 5 records to
> worry about.
>
>
> > Meanwhile, I will log in and see what I can find from
> your server...
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:02 PM
> >> On Sep 19, 2010, at 12:15 PM, Flavio
> >> Smirne wrote:
> >>
> >>> One question I have is why is the server
> sending
> >> windows line
> >>> endings in the first place? They should be
> sending
> >> "\n" only as
> >>> pretty much everyone understands that. It
> seems that
> >> they are
> >>> sending "\n" but are trying to send an extra
> windows
> >> line ending "\r
> >>> \n" for some reason.
> >>
> >>
> >>> The part that bothers me the most is the "0d
> 0d 0a"
> >> line ending you
> >>> are talking about. The extra 0d or "0d 0a"
> doesn't
> >> look right at
> >>> all. Whatever is the reason they are doing
> that, I
> >> don't think the
> >>> extra line ending should be there.
> >>
> >> I agree ... that's part of the problem. Depending
> on the
> >> context, the
> >> various standards (including the RETS standard)
> call for
> >> CR/LF line
> >> termination (also see RFC2616, RFC2045 and
> friends) ...
> >> it's that
> >> extra CR causing issues. Note that the normal
> line
> >> termination on Unix
> >> is LF - on Windows, it's CR. That's why I suspect
> something
> >> Windows-
> >> ish is getting in the way.
> >>
> >>>
> >> In any event, in this portion of the payload, the
> line
> >> termination is
> >> moot, so long as it is accounted for by the
> >> chunked-encoding count.
> >>
> >>> AFAIK, the MRED RETS server runs on a FreeBSD
> box, but
> >> I could be
> >>> wrong.
> >>
> >> I use FreeBSD and am running the Variman RETS
> server here.
> >> Why don't
> >> you try your application pointing at my server and
> see what
> >> you get? http://www.dis.com:6103/rets/login
> >> . User: Joe Password: Schmoe. If that's
> successful, we can
> >> try a
> >> contrived test with my playback tool where I play
> back your
> >> log to
> >> you ... that might give a clue as to what's adding
> the
> >> extra CR.
> >>
> >>
> >>
> >>
> >> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 2:24 PM, Flavio Smirne wrote:

> .NET query (librets)
>
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
>
> Answer:
>
>

You're not setting the RETS version on the client side, so it is
defaulting to 1.0. On the server side, Variman no longer supports RETS
1.0, hence the error.

> The 2 queries look exactly the same to me, except for the
> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).

Are you doing any encoding or just letting libRETS handle it? This
almost looks like it's double encoded.

>
> Any ideas?
>
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 3:40 PM
>> On Sep 19, 2010, at 1:31 PM, Flavio
>> Smirne wrote:
>>
>>> I'm ready to send a request. Do you want me to request
>> for a
>>> specific LN?
>>
>>
>> Try query "(ListPrice=0+)". There are only 5 records to
>> worry about.
>>
>>
>>> Meanwhile, I will log in and see what I can find from
>> your server...
>>>
>>> Flavio
>>>
>>> --- On Sun, 9/19/10, Mark Klein <>
>> wrote:
>>>
>>>> From: Mark Klein <>
>>>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
>> File
>>>> To: "For discussion and help for and by the users
>> of the libRETS C+
>>>> + library"
>>>> Date: Sunday, September 19, 2010, 3:02 PM
>>>> On Sep 19, 2010, at 12:15 PM, Flavio
>>>> Smirne wrote:
>>>>
>>>>> One question I have is why is the server
>> sending
>>>> windows line
>>>>> endings in the first place? They should be
>> sending
>>>> "\n" only as
>>>>> pretty much everyone understands that. It
>> seems that
>>>> they are
>>>>> sending "\n" but are trying to send an extra
>> windows
>>>> line ending "\r
>>>>> \n" for some reason.
>>>>
>>>>
>>>>> The part that bothers me the most is the "0d
>> 0d 0a"
>>>> line ending you
>>>>> are talking about. The extra 0d or "0d 0a"
>> doesn't
>>>> look right at
>>>>> all. Whatever is the reason they are doing
>> that, I
>>>> don't think the
>>>>> extra line ending should be there.
>>>>
>>>> I agree ... that's part of the problem. Depending
>> on the
>>>> context, the
>>>> various standards (including the RETS standard)
>> call for
>>>> CR/LF line
>>>> termination (also see RFC2616, RFC2045 and
>> friends) ...
>>>> it's that
>>>> extra CR causing issues. Note that the normal
>> line
>>>> termination on Unix
>>>> is LF - on Windows, it's CR. That's why I suspect
>> something
>>>> Windows-
>>>> ish is getting in the way.
>>>>
>>>>>
>>>> In any event, in this portion of the payload, the
>> line
>>>> termination is
>>>> moot, so long as it is accounted for by the
>>>> chunked-encoding count.
>>>>
>>>>> AFAIK, the MRED RETS server runs on a FreeBSD
>> box, but
>>>> I could be
>>>>> wrong.
>>>>
>>>> I use FreeBSD and am running the Variman RETS
>> server here.
>>>> Why don't
>>>> you try your application pointing at my server and
>> see what
>>>> you get? http://www.dis.com:6103/rets/login
>>>> . User: Joe Password: Schmoe. If that's
>> successful, we can
>>>> try a
>>>> contrived test with my playback tool where I play
>> back your
>>>> log to
>>>> you ... that might give a clue as to what's adding
>> the
>>>> extra CR.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. Awesome! After setting the version and getting rid of the double encoding, everything worked fine.

I wonder if the original problem wasn't related to me not setting the version... I will try playing with that as well...

I'm sending the log to you at librets-logs (at) crt.realtors.org

Flavio


--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 4:54 PM
> On Sep 19, 2010, at 2:24 PM, Flavio
> Smirne wrote:
>
> > .NET query (librets)
> >
> >
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
>
> >
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
> >
> > Answer:
> >
> >
>
> You're not setting the RETS version on the client side, so
> it is 
> defaulting to 1.0. On the server side, Variman no longer
> supports RETS 
> 1.0, hence the error.
>
> > The 2 queries look exactly the same to me, except for
> the 
> > %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
>
> Are you doing any encoding or just letting libRETS handle
> it? This 
> almost looks like it's double encoded.
>
> >
> > Any ideas?
> >
> >
> > Flavio
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 3:40 PM
> >> On Sep 19, 2010, at 1:31 PM, Flavio
> >> Smirne wrote:
> >>
> >>> I'm ready to send a request. Do you want me to
> request
> >> for a
> >>> specific LN?
> >>
> >>
> >> Try query "(ListPrice=0+)". There are only 5
> records to
> >> worry about.
> >>
> >>
> >>> Meanwhile, I will log in and see what I can
> find from
> >> your server...
> >>>
> >>> Flavio
> >>>
> >>> --- On Sun, 9/19/10, Mark Klein <>
> >> wrote:
> >>>
> >>>> From: Mark Klein <>
> >>>> Subject: Re: [libRETS-users] [ezRETS-logs]
> New Log
> >> File
> >>>> To: "For discussion and help for and by
> the users
> >> of the libRETS C+
> >>>> + library"
> >>>> Date: Sunday, September 19, 2010, 3:02 PM
> >>>> On Sep 19, 2010, at 12:15 PM, Flavio
> >>>> Smirne wrote:
> >>>>
> >>>>> One question I have is why is the
> server
> >> sending
> >>>> windows line
> >>>>> endings in the first place? They
> should be
> >> sending
> >>>> "\n" only as
> >>>>> pretty much everyone understands that.
> It
> >> seems that
> >>>> they are
> >>>>> sending "\n" but are trying to send an
> extra
> >> windows
> >>>> line ending "\r
> >>>>> \n" for some reason.
> >>>>
> >>>>
> >>>>> The part that bothers me the most is
> the "0d
> >> 0d 0a"
> >>>> line ending you
> >>>>> are talking about. The extra 0d or "0d
> 0a"
> >> doesn't
> >>>> look right at
> >>>>> all. Whatever is the reason they are
> doing
> >> that, I
> >>>> don't think the
> >>>>> extra line ending should be there.
> >>>>
> >>>> I agree ... that's part of the problem.
> Depending
> >> on the
> >>>> context, the
> >>>> various standards (including the RETS
> standard)
> >> call for
> >>>> CR/LF line
> >>>> termination (also see RFC2616, RFC2045
> and
> >> friends) ...
> >>>> it's that
> >>>> extra CR causing issues. Note that the
> normal
> >> line
> >>>> termination on Unix
> >>>> is LF - on Windows, it's CR. That's why I
> suspect
> >> something
> >>>> Windows-
> >>>> ish is getting in the way.
> >>>>
> >>>>>
> >>>> In any event, in this portion of the
> payload, the
> >> line
> >>>> termination is
> >>>> moot, so long as it is accounted for by
> the
> >>>> chunked-encoding count.
> >>>>
> >>>>> AFAIK, the MRED RETS server runs on a
> FreeBSD
> >> box, but
> >>>> I could be
> >>>>> wrong.
> >>>>
> >>>> I use FreeBSD and am running the Variman
> RETS
> >> server here.
> >>>> Why don't
> >>>> you try your application pointing at my
> server and
> >> see what
> >>>> you get? http://www.dis.com:6103/rets/login
> >>>> . User: Joe Password: Schmoe. If that's
> >> successful, we can
> >>>> try a
> >>>> contrived test with my playback tool where
> I play
> >> back your
> >>>> log to
> >>>> you ... that might give a clue as to
> what's adding
> >> the
> >>>> extra CR.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 19, 2010, at 3:07 PM, Flavio Smirne wrote:

> Awesome! After setting the version and getting rid of the double
> encoding, everything worked fine.
>
> I wonder if the original problem wasn't related to me not setting
> the version... I will try playing with that as well...

I don't see how the version differences would cause the server to send
invalid chunked-encoded data. Nevertheless, it's worth a try.

>
> I'm sending the log to you at librets-logs (at) crt.realtors.org

I was concerned that your system was the one adding the extra CR ..
it's not. The log you sent me this last time was formatted exactly as
I would expect. It is supposed to be the raw data seen by libCURL
(which we use to abstract away all the html goo) and since this log is
exactly what I expected, I'm convinced it is the server side adding
the extra characters and not accounting for them.


>
> Flavio
>
>
> --- On Sun, 9/19/10, Mark Klein <> wrote:
>
>> From: Mark Klein <>
>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
>> To: "For discussion and help for and by the users of the libRETS C+
>> + library"
>> Date: Sunday, September 19, 2010, 4:54 PM
>> On Sep 19, 2010, at 2:24 PM, Flavio
>> Smirne wrote:
>>
>>> .NET query (librets)
>>>
>>>
>> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
>>
>>>
>> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
>>>
>>> Answer:
>>>
>>>
>>
>> You're not setting the RETS version on the client side, so
>> it is
>> defaulting to 1.0. On the server side, Variman no longer
>> supports RETS
>> 1.0, hence the error.
>>
>>> The 2 queries look exactly the same to me, except for
>> the
>>> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
>>
>> Are you doing any encoding or just letting libRETS handle
>> it? This
>> almost looks like it's double encoded.
>>
>>>
>>> Any ideas?
>>>
>>>
>>> Flavio
>>>
>>> --- On Sun, 9/19/10, Mark Klein <>
>> wrote:
>>>
>>>> From: Mark Klein <>
>>>> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
>> File
>>>> To: "For discussion and help for and by the users
>> of the libRETS C+
>>>> + library"
>>>> Date: Sunday, September 19, 2010, 3:40 PM
>>>> On Sep 19, 2010, at 1:31 PM, Flavio
>>>> Smirne wrote:
>>>>
>>>>> I'm ready to send a request. Do you want me to
>> request
>>>> for a
>>>>> specific LN?
>>>>
>>>>
>>>> Try query "(ListPrice=0+)". There are only 5
>> records to
>>>> worry about.
>>>>
>>>>
>>>>> Meanwhile, I will log in and see what I can
>> find from
>>>> your server...
>>>>>
>>>>> Flavio
>>>>>
>>>>> --- On Sun, 9/19/10, Mark Klein <>
>>>> wrote:
>>>>>
>>>>>> From: Mark Klein <>
>>>>>> Subject: Re: [libRETS-users] [ezRETS-logs]
>> New Log
>>>> File
>>>>>> To: "For discussion and help for and by
>> the users
>>>> of the libRETS C+
>>>>>> + library"
>>>>>> Date: Sunday, September 19, 2010, 3:02 PM
>>>>>> On Sep 19, 2010, at 12:15 PM, Flavio
>>>>>> Smirne wrote:
>>>>>>
>>>>>>> One question I have is why is the
>> server
>>>> sending
>>>>>> windows line
>>>>>>> endings in the first place? They
>> should be
>>>> sending
>>>>>> "\n" only as
>>>>>>> pretty much everyone understands that.
>> It
>>>> seems that
>>>>>> they are
>>>>>>> sending "\n" but are trying to send an
>> extra
>>>> windows
>>>>>> line ending "\r
>>>>>>> \n" for some reason.
>>>>>>
>>>>>>
>>>>>>> The part that bothers me the most is
>> the "0d
>>>> 0d 0a"
>>>>>> line ending you
>>>>>>> are talking about. The extra 0d or "0d
>> 0a"
>>>> doesn't
>>>>>> look right at
>>>>>>> all. Whatever is the reason they are
>> doing
>>>> that, I
>>>>>> don't think the
>>>>>>> extra line ending should be there.
>>>>>>
>>>>>> I agree ... that's part of the problem.
>> Depending
>>>> on the
>>>>>> context, the
>>>>>> various standards (including the RETS
>> standard)
>>>> call for
>>>>>> CR/LF line
>>>>>> termination (also see RFC2616, RFC2045
>> and
>>>> friends) ...
>>>>>> it's that
>>>>>> extra CR causing issues. Note that the
>> normal
>>>> line
>>>>>> termination on Unix
>>>>>> is LF - on Windows, it's CR. That's why I
>> suspect
>>>> something
>>>>>> Windows-
>>>>>> ish is getting in the way.
>>>>>>
>>>>>>>
>>>>>> In any event, in this portion of the
>> payload, the
>>>> line
>>>>>> termination is
>>>>>> moot, so long as it is accounted for by
>> the
>>>>>> chunked-encoding count.
>>>>>>
>>>>>>> AFAIK, the MRED RETS server runs on a
>> FreeBSD
>>>> box, but
>>>>>> I could be
>>>>>>> wrong.
>>>>>>
>>>>>> I use FreeBSD and am running the Variman
>> RETS
>>>> server here.
>>>>>> Why don't
>>>>>> you try your application pointing at my
>> server and
>>>> see what
>>>>>> you get? http://www.dis.com:6103/rets/login
>>>>>> . User: Joe Password: Schmoe. If that's
>>>> successful, we can
>>>>>> try a
>>>>>> contrived test with my playback tool where
>> I play
>>>> back your
>>>>>> log to
>>>>>> you ... that might give a clue as to
>> what's adding
>>>> the
>>>>>> extra CR.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. Setting the version didn't help as expected...
I will wait for an answer from MRED and once I find a solution, I will post it back here so the next person doesn't run into the same problem :)

Thanks for helping me track this down!

Flavio

--- On Sun, 9/19/10, Mark Klein <> wrote:

> From: Mark Klein <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 7:20 PM
> On Sep 19, 2010, at 3:07 PM, Flavio
> Smirne wrote:
>
> > Awesome! After setting the version and getting rid of
> the double 
> > encoding, everything worked fine.
> >
> > I wonder if the original problem wasn't related to me
> not setting 
> > the version... I will try playing with that as
> well...
>
> I don't see how the version differences would cause the
> server to send 
> invalid chunked-encoded data. Nevertheless, it's worth a
> try.
>
> >
> > I'm sending the log to you at librets-logs (at)
> crt.realtors.org
>
> I was concerned that your system was the one adding the
> extra CR .. 
> it's not. The log you sent me this last time was formatted
> exactly as 
> I would expect. It is supposed to be the raw data seen by
> libCURL 
> (which we use to abstract away all the html goo) and since
> this log is 
> exactly what I expected, I'm convinced it is the server
> side adding 
> the extra characters and not accounting for them.
>
>
> >
> > Flavio
> >
> >
> > --- On Sun, 9/19/10, Mark Klein <>
> wrote:
> >
> >> From: Mark Klein <>
> >> Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> >> To: "For discussion and help for and by the users
> of the libRETS C+
> >> + library"
> >> Date: Sunday, September 19, 2010, 4:54 PM
> >> On Sep 19, 2010, at 2:24 PM, Flavio
> >> Smirne wrote:
> >>
> >>> .NET query (librets)
> >>>
> >>>
> >>
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
> >>
> >>>
> >>
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
> >>>
> >>> Answer:
> >>>
> >>> > ReplyText="Miscellaneous
> >> Search Error:
> >>> Invalid query type: DMQL"/>
> >>
> >> You're not setting the RETS version on the client
> side, so
> >> it is
> >> defaulting to 1.0. On the server side, Variman no
> longer
> >> supports RETS
> >> 1.0, hence the error.
> >>
> >>> The 2 queries look exactly the same to me,
> except for
> >> the
> >>> %28ListPrice=0%2B%29 vs (ListPrice%3d0%252B).
> >>
> >> Are you doing any encoding or just letting libRETS
> handle
> >> it? This
> >> almost looks like it's double encoded.
> >>
> >>>
> >>> Any ideas?
> >>>
> >>>
> >>> Flavio
> >>>
> >>> --- On Sun, 9/19/10, Mark Klein <>
> >> wrote:
> >>>
> >>>> From: Mark Klein <>
> >>>> Subject: Re: [libRETS-users] [ezRETS-logs]
> New Log
> >> File
> >>>> To: "For discussion and help for and by
> the users
> >> of the libRETS C+
> >>>> + library"
> >>>> Date: Sunday, September 19, 2010, 3:40 PM
> >>>> On Sep 19, 2010, at 1:31 PM, Flavio
> >>>> Smirne wrote:
> >>>>
> >>>>> I'm ready to send a request. Do you
> want me to
> >> request
> >>>> for a
> >>>>> specific LN?
> >>>>
> >>>>
> >>>> Try query "(ListPrice=0+)". There are only
> 5
> >> records to
> >>>> worry about.
> >>>>
> >>>>
> >>>>> Meanwhile, I will log in and see what
> I can
> >> find from
> >>>> your server...
> >>>>>
> >>>>> Flavio
> >>>>>
> >>>>> --- On Sun, 9/19/10, Mark Klein <>
> >>>> wrote:
> >>>>>
> >>>>>> From: Mark Klein <>
> >>>>>> Subject: Re: [libRETS-users]
> [ezRETS-logs]
> >> New Log
> >>>> File
> >>>>>> To: "For discussion and help for
> and by
> >> the users
> >>>> of the libRETS C+
> >>>>>> + library"
> >>>>>> Date: Sunday, September 19, 2010,
> 3:02 PM
> >>>>>> On Sep 19, 2010, at 12:15 PM,
> Flavio
> >>>>>> Smirne wrote:
> >>>>>>
> >>>>>>> One question I have is why is
> the
> >> server
> >>>> sending
> >>>>>> windows line
> >>>>>>> endings in the first place?
> They
> >> should be
> >>>> sending
> >>>>>> "\n" only as
> >>>>>>> pretty much everyone
> understands that.
> >> It
> >>>> seems that
> >>>>>> they are
> >>>>>>> sending "\n" but are trying to
> send an
> >> extra
> >>>> windows
> >>>>>> line ending "\r
> >>>>>>> \n" for some reason.
> >>>>>>
> >>>>>>
> >>>>>>> The part that bothers me the
> most is
> >> the "0d
> >>>> 0d 0a"
> >>>>>> line ending you
> >>>>>>> are talking about. The extra
> 0d or "0d
> >> 0a"
> >>>> doesn't
> >>>>>> look right at
> >>>>>>> all. Whatever is the reason
> they are
> >> doing
> >>>> that, I
> >>>>>> don't think the
> >>>>>>> extra line ending should be
> there.
> >>>>>>
> >>>>>> I agree ... that's part of the
> problem.
> >> Depending
> >>>> on the
> >>>>>> context, the
> >>>>>> various standards (including the
> RETS
> >> standard)
> >>>> call for
> >>>>>> CR/LF line
> >>>>>> termination (also see RFC2616,
> RFC2045
> >> and
> >>>> friends) ...
> >>>>>> it's that
> >>>>>> extra CR causing issues. Note that
> the
> >> normal
> >>>> line
> >>>>>> termination on Unix
> >>>>>> is LF - on Windows, it's CR.
> That's why I
> >> suspect
> >>>> something
> >>>>>> Windows-
> >>>>>> ish is getting in the way.
> >>>>>>
> >>>>>>>
> >>>>>> In any event, in this portion of
> the
> >> payload, the
> >>>> line
> >>>>>> termination is
> >>>>>> moot, so long as it is accounted
> for by
> >> the
> >>>>>> chunked-encoding count.
> >>>>>>
> >>>>>>> AFAIK, the MRED RETS server
> runs on a
> >> FreeBSD
> >>>> box, but
> >>>>>> I could be
> >>>>>>> wrong.
> >>>>>>
> >>>>>> I use FreeBSD and am running the
> Variman
> >> RETS
> >>>> server here.
> >>>>>> Why don't
> >>>>>> you try your application pointing
> at my
> >> server and
> >>>> see what
> >>>>>> you get? http://www.dis.com:6103/rets/login
> >>>>>> . User: Joe Password: Schmoe. If
> that's
> >>>> successful, we can
> >>>>>> try a
> >>>>>> contrived test with my playback
> tool where
> >> I play
> >>>> back your
> >>>>>> log to
> >>>>>> you ... that might give a clue as
> to
> >> what's adding
> >>>> the
> >>>>>> extra CR.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. Ok. I haven't heard back from the vendor yet, but I came up with 2 workarounds for this problem:

1) Instead of calling RetsSession.Search(request), one could make the following calls:

byte[] foo = Session.SearchAsArray(req);
string test = System.Text.Encoding.UTF8.GetString(foo);

This gives the correct encoded string, but I lose all the parsing functionality of libRETS. Not very good, since I don't want to parse the data myself.

2) Call SearchResultSet results = RetsSession.Search(request) normally, but then do the following to correct the encoding:

string rem = results.GetString("REMARKS");
byte[] decoded = System.Text.Encoding.Default.GetBytes(rem);
correct = System.Text.Encoding.UTF8.GetString(decoded);

This is not an ideal solution, but it does work. I still believe that there's a way to set the correct encoding at some level and get all this done for free, but I wanted to play with this and find a workaround in case the vendor doesn't give me an acceptable solution.

I hope this helps someone...

Thanks,

Flavio

--- On Sun, 9/19/10, Flavio Smirne <> wrote:

> From: Flavio Smirne <>
> Subject: Re: [libRETS-users] [ezRETS-logs] New Log File
> To: "For discussion and help for and by the users of the libRETS C++ library"
> Date: Sunday, September 19, 2010, 11:06 PM
> Setting the version didn't help as
> expected...
> I will wait for an answer from MRED and once I find a
> solution, I will post it back here so the next person
> doesn't run into the same problem :)
>
> Thanks for helping me track this down!
>
> Flavio
>
> --- On Sun, 9/19/10, Mark Klein <>
> wrote:
>
> > From: Mark Klein <>
> > Subject: Re: [libRETS-users] [ezRETS-logs] New Log
> File
> > To: "For discussion and help for and by the users of
> the libRETS C++ library"
> > Date: Sunday, September 19, 2010, 7:20 PM
> > On Sep 19, 2010, at 3:07 PM, Flavio
> > Smirne wrote:
> >
> > > Awesome! After setting the version and getting
> rid of
> > the double 
> > > encoding, everything worked fine.
> > >
> > > I wonder if the original problem wasn't related
> to me
> > not setting 
> > > the version... I will try playing with that as
> > well...
> >
> > I don't see how the version differences would cause
> the
> > server to send 
> > invalid chunked-encoded data. Nevertheless, it's worth
> a
> > try.
> >
> > >
> > > I'm sending the log to you at librets-logs (at)
> > crt.realtors.org
> >
> > I was concerned that your system was the one adding
> the
> > extra CR .. 
> > it's not. The log you sent me this last time was
> formatted
> > exactly as 
> > I would expect. It is supposed to be the raw data seen
> by
> > libCURL 
> > (which we use to abstract away all the html goo) and
> since
> > this log is 
> > exactly what I expected, I'm convinced it is the
> server
> > side adding 
> > the extra characters and not accounting for them.
> >
> >
> > >
> > > Flavio
> > >
> > >
> > > --- On Sun, 9/19/10, Mark Klein <>
> > wrote:
> > >
> > >> From: Mark Klein <>
> > >> Subject: Re: [libRETS-users] [ezRETS-logs]
> New Log
> > File
> > >> To: "For discussion and help for and by the
> users
> > of the libRETS C+
> > >> + library"
> > >> Date: Sunday, September 19, 2010, 4:54 PM
> > >> On Sep 19, 2010, at 2:24 PM, Flavio
> > >> Smirne wrote:
> > >>
> > >>> .NET query (librets)
> > >>>
> > >>>
> > >>
> >
> Class=RES&Count=1&Format=COMPACT-DECODED&Offset=1&Query=(ListPrice
> > >>
> > >>>
> > >>
> >
> %3d0%252B)&QueryType=DMQL&SearchType=Property&StandardNames=0
> > >>>
> > >>> Answer:
> > >>>
> > >>> > > ReplyText="Miscellaneous
> > >> Search Error:
> > >>> Invalid query type: DMQL"/>
> > >>
> > >> You're not setting the RETS version on the
> client
> > side, so
> > >> it is
> > >> defaulting to 1.0. On the server side,
> Variman no
> > longer
> > >> supports RETS
> > >> 1.0, hence the error.
> > >>
> > >>> The 2 queries look exactly the same to
> me,
> > except for
> > >> the
> > >>> %28ListPrice=0%2B%29 vs
> (ListPrice%3d0%252B).
> > >>
> > >> Are you doing any encoding or just letting
> libRETS
> > handle
> > >> it? This
> > >> almost looks like it's double encoded.
> > >>
> > >>>
> > >>> Any ideas?
> > >>>
> > >>>
> > >>> Flavio
> > >>>
> > >>> --- On Sun, 9/19/10, Mark Klein <>
> > >> wrote:
> > >>>
> > >>>> From: Mark Klein <>
> > >>>> Subject: Re: [libRETS-users]
> [ezRETS-logs]
> > New Log
> > >> File
> > >>>> To: "For discussion and help for and
> by
> > the users
> > >> of the libRETS C+
> > >>>> + library"
> > >>>> Date: Sunday, September 19, 2010,
> 3:40 PM
> > >>>> On Sep 19, 2010, at 1:31 PM, Flavio
> > >>>> Smirne wrote:
> > >>>>
> > >>>>> I'm ready to send a request. Do
> you
> > want me to
> > >> request
> > >>>> for a
> > >>>>> specific LN?
> > >>>>
> > >>>>
> > >>>> Try query "(ListPrice=0+)". There are
> only
> > 5
> > >> records to
> > >>>> worry about.
> > >>>>
> > >>>>
> > >>>>> Meanwhile, I will log in and see
> what
> > I can
> > >> find from
> > >>>> your server...
> > >>>>>
> > >>>>> Flavio
> > >>>>>
> > >>>>> --- On Sun, 9/19/10, Mark Klein
> <>
> > >>>> wrote:
> > >>>>>
> > >>>>>> From: Mark Klein <>
> > >>>>>> Subject: Re: [libRETS-users]
> > [ezRETS-logs]
> > >> New Log
> > >>>> File
> > >>>>>> To: "For discussion and help
> for
> > and by
> > >> the users
> > >>>> of the libRETS C+
> > >>>>>> + library"
> > >>>>>> Date: Sunday, September 19,
> 2010,
> > 3:02 PM
> > >>>>>> On Sep 19, 2010, at 12:15
> PM,
> > Flavio
> > >>>>>> Smirne wrote:
> > >>>>>>
> > >>>>>>> One question I have is
> why is
> > the
> > >> server
> > >>>> sending
> > >>>>>> windows line
> > >>>>>>> endings in the first
> place?
> > They
> > >> should be
> > >>>> sending
> > >>>>>> "\n" only as
> > >>>>>>> pretty much everyone
> > understands that.
> > >> It
> > >>>> seems that
> > >>>>>> they are
> > >>>>>>> sending "\n" but are
> trying to
> > send an
> > >> extra
> > >>>> windows
> > >>>>>> line ending "\r
> > >>>>>>> \n" for some reason.
> > >>>>>>
> > >>>>>>
> > >>>>>>> The part that bothers me
> the
> > most is
> > >> the "0d
> > >>>> 0d 0a"
> > >>>>>> line ending you
> > >>>>>>> are talking about. The
> extra
> > 0d or "0d
> > >> 0a"
> > >>>> doesn't
> > >>>>>> look right at
> > >>>>>>> all. Whatever is the
> reason
> > they are
> > >> doing
> > >>>> that, I
> > >>>>>> don't think the
> > >>>>>>> extra line ending should
> be
> > there.
> > >>>>>>
> > >>>>>> I agree ... that's part of
> the
> > problem.
> > >> Depending
> > >>>> on the
> > >>>>>> context, the
> > >>>>>> various standards (including
> the
> > RETS
> > >> standard)
> > >>>> call for
> > >>>>>> CR/LF line
> > >>>>>> termination (also see
> RFC2616,
> > RFC2045
> > >> and
> > >>>> friends) ...
> > >>>>>> it's that
> > >>>>>> extra CR causing issues. Note
> that
> > the
> > >> normal
> > >>>> line
> > >>>>>> termination on Unix
> > >>>>>> is LF - on Windows, it's CR.
> > That's why I
> > >> suspect
> > >>>> something
> > >>>>>> Windows-
> > >>>>>> ish is getting in the way.
> > >>>>>>
> > >>>>>>>
> > >>>>>> In any event, in this portion
> of
> > the
> > >> payload, the
> > >>>> line
> > >>>>>> termination is
> > >>>>>> moot, so long as it is
> accounted
> > for by
> > >> the
> > >>>>>> chunked-encoding count.
> > >>>>>>
> > >>>>>>> AFAIK, the MRED RETS
> server
> > runs on a
> > >> FreeBSD
> > >>>> box, but
> > >>>>>> I could be
> > >>>>>>> wrong.
> > >>>>>>
> > >>>>>> I use FreeBSD and am running
> the
> > Variman
> > >> RETS
> > >>>> server here.
> > >>>>>> Why don't
> > >>>>>> you try your application
> pointing
> > at my
> > >> server and
> > >>>> see what
> > >>>>>> you get? http://www.dis.com:6103/rets/login
> > >>>>>> . User: Joe Password: Schmoe.
> If
> > that's
> > >>>> successful, we can
> > >>>>>> try a
> > >>>>>> contrived test with my
> playback
> > tool where
> > >> I play
> > >>>> back your
> > >>>>>> log to
> > >>>>>> you ... that might give a
> clue as
> > to
> > >> what's adding
> > >>>> the
> > >>>>>> extra CR.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>
> _______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe. On Sep 20, 2010, at 11:01 PM, Flavio Smirne wrote:

> Ok. I haven't heard back from the vendor yet, but I came up with 2
> workarounds for this problem:
>
> 1) Instead of calling RetsSession.Search(request), one could make
> the following calls:
>
> byte[] foo = Session.SearchAsArray(req);

How about writing foo to a file, zipping it up and sending it to me?
There's still something funky going on because based on the earlier
logs you sent me, libRETS should throw an exception because it never
sees the trailing tag for the chunked-encoding length issue.
In throwing that exception, you shouldn't be able to use the results
at all.

Add a try/catch around things and make sure there is a message being
printed in the catch to be sure that there isn't an exception being
masked somehow.

> string test = System.Text.Encoding.UTF8.GetString(foo);
>
> This gives the correct encoded string, but I lose all the parsing
> functionality of libRETS. Not very good, since I don't want to parse
> the data myself.

Actually, if the data is intact, you can inject it back into the
parser. This is an advanced libRETS feature that can be used for
performance: you capture all the search data as quickly as you can,
shutdown the connection, and then parse and process the data. See: https://code.crt.realtors.org/projects/librets/browser/librets/trunk/project/swig/csharp/RawSearch.cs
for a sample implementation. But, that's really the subject for
another post.

> 2) Call SearchResultSet results = RetsSession.Search(request)
> normally, but then do the following to correct the encoding:
>
> string rem = results.GetString("REMARKS");
> byte[] decoded = System.Text.Encoding.Default.GetBytes(rem);
> correct = System.Text.Encoding.UTF8.GetString(decoded);

If libRETS is in fact providing you an intact view of the data, then
this is your solution. libRETS does not process the data other than to
call expat (the XML parser library) to scan and parse the XML into
proper elements. From there, libRETS only returns the content of those
elements to you upon request. So, if the data you're getting back is
"garbled" because of the encoding, this is your best solution.

> This is not an ideal solution, but it does work. I still believe
> that there's a way to set the correct encoding at some level and get
> all this done for free, but I wanted to play with this and find a
> workaround in case the vendor doesn't give me an acceptable solution.

Now this is gonna drive me nuts. From the log file you sent me, you
shouldn't be able to do this. Can you run tcpdump or wireshark or some
other network tracing tool and capture the actual packets on the wire?
I've gotta make sure that there isn't something in the network stack
before the data gets to libRETS that isn't mucking with the chunked-
encoding length.

Regards,



M.

_______________________________________________
___________________________________________________

Posted on the LibRETS-users mailing list. Go to http://mail.crt.realtors.org/mailman/listinfo/librets-users to subscribe.