please see my other email.
it's somehow related to the wrapped payload.
that's the reason why GET requests work fin with Base64 encoded responses,
but POST fails. The HTTPD doesn't unwrap POST response payload before encoding.
Why that is, still remains an open question.
Ike
On Mar 22, 2011, at 12:09 AM, Jason Greene wrote:
I briefly glanced at this today and will look into it more tonight, I
noticed that we did not do a dmr release upgrade for as yet, so for sure it's not the
base64 routine. This also means the flush issue is still there.
Sent from my iPhone
On Mar 21, 2011, at 5:20 PM, Jonathan Pearlin <jpearlin1(a)gmail.com> wrote:
> From the testing I was able to do with the string provided (and some that I
generated), it appears that everything works fine if the Base64 encoded string is
complete. The string provided definitely appears to have been cut off. I feel as though
we are looking in the wrong place: we should try to see if we can re-create whatever
caused the response to be cut short (is it possible that the HTML response was cut off,
which caused the whole problem or can you repeat this every time)? My suspicion is that
we will find something wrong with the encoding side.
>
> --Jonathan
>
> On Mon, Mar 21, 2011 at 11:49 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
>
>
> Yeah, that's what I see as well.
> But I cannot identify the changes that could have caused this problem.
>
> Ike
>
> On Mar 19, 2011, at 3:57 AM, Jason Greene wrote:
>
> >> Second, it appears that the Base64 encoded string is cut off
>
>