Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Tricky Request Filtering Issue

Reply
Thread Tools

Tricky Request Filtering Issue

 
 
Joseph Geretz
Guest
Posts: n/a
 
      09-03-2008
I'm using the Request Filter documentation which can be found here:

http://msdn.microsoft.com/en-us/libr...st.filter.aspx

In this example, two filters are installed, one filter uppercases every
alphabetic character and then the second filter replaces every 'E' with "#'.
OK, very nice.

What's trivial about these examples is that the returned string is exactly
the same length as the string which is actually read from the Request
stream. I have a slightly more complicated situation where I'm using a
Filter to decrypt the data which is pulled from the Request stream. (I'm
implementing cryptography in the Filter so that application developers don't
need to worry about dealing with this issue; application developers simply
retrieve Request data and the filter ensures that it is always delivered in
PlainText, regardless of whether it was POSTed in cipher or plain text.)

So how do I deal with this issue, where the Request stream contains let's
say 2000 bytes, yet the decrypted plaintext is now only 1000 bytes? If I
return a count of 1000, then the Read event fires again, seemingly because
it appears as though there remains 1000 bytes to remove form the stream. If
I return the original count, then the buffer returned is much too large,
larger than the actual data which causes problems when attmepting to decrypt
the ciphertext. I'f you've ever developed such a scenario, I appreciate any
advice which you can provide.

Thanks!

- Joseph Geretz -


 
Reply With Quote
 
 
 
 
bruce barker
Guest
Posts: n/a
 
      09-03-2008
i'm not sure what your problem is. the filter is a stream, you read the
stream in, and write it out modified anyway your want. nothing says you
have to write the same number of bytes you read.

-- bruce (sqlwork.com)


Joseph Geretz wrote:
> I'm using the Request Filter documentation which can be found here:
>
> http://msdn.microsoft.com/en-us/libr...st.filter.aspx
>
> In this example, two filters are installed, one filter uppercases every
> alphabetic character and then the second filter replaces every 'E' with "#'.
> OK, very nice.
>
> What's trivial about these examples is that the returned string is exactly
> the same length as the string which is actually read from the Request
> stream. I have a slightly more complicated situation where I'm using a
> Filter to decrypt the data which is pulled from the Request stream. (I'm
> implementing cryptography in the Filter so that application developers don't
> need to worry about dealing with this issue; application developers simply
> retrieve Request data and the filter ensures that it is always delivered in
> PlainText, regardless of whether it was POSTed in cipher or plain text.)
>
> So how do I deal with this issue, where the Request stream contains let's
> say 2000 bytes, yet the decrypted plaintext is now only 1000 bytes? If I
> return a count of 1000, then the Read event fires again, seemingly because
> it appears as though there remains 1000 bytes to remove form the stream. If
> I return the original count, then the buffer returned is much too large,
> larger than the actual data which causes problems when attmepting to decrypt
> the ciphertext. I'f you've ever developed such a scenario, I appreciate any
> advice which you can provide.
>
> Thanks!
>
> - Joseph Geretz -
>
>

 
Reply With Quote
 
 
 
 
Joseph Geretz
Guest
Posts: n/a
 
      09-03-2008
Hi Bruce,

I'm not 100% sure myself what the problem is. I'm seeing a number of
anomalies. Perhaps you can help me 'peel this onion' to get to the bottom of
the problem.

In addition to the Request Filter, my application implements an HttpModule.
The module's purpose in life is basically to wire up the Request and
Response filters at the start of each transaction. The module will also log
the request and do certain other application wide processing. Here's the
code in the HttpModule which attempts to get the body of the Request:

(I've numbered these lines just for the clarity of the discussion.)

private string zGetRequestBody(HttpContext httpCtx)
{
1. byte[] buffer = new byte[httpCtx.Request.InputStream.Length];
2. httpCtx.Request.InputStream.Read(buffer, 0,
(int)httpCtx.Request.InputStream.Length);
3. return Encoding.UTF8.GetString(buffer, 0, buffer.Length);
}

The first anomaly I am noticing is that line 1 triggers the *Read* method of
my Request filter (huh?):

public override int Read(byte[] buffer, int offset, int count)
{
int ContentLength;
ContentLength = m_sink.Read(buffer, offset, count);
return ContentLength;
}

(Actually, I observe this method fire twice, for this line of code.)

Now why in the world would this be happening? I've set a breakpoin in the
Length method, yet this breakpoint is never hit!!

public override long Length
{
get { return m_sink.Length; }
}

So this is my first question on the way to figuring this out: Why does
httpCtx.Request.InputStream.Length trigger the *Read* method of my filter?
Shouldn't it be triggering the Length property?? At this point, I've
completely removed the entire issue of encryption/decryption from the
excercise. The code I've got in place now works without
encryption/decryption. but I simply don't understand the mechanics and when
I add encryption/decryption which dynamically changes the length, things go
from bad to worse. I suspect that the matter will ultimately resolve itself
as you suggest, however the first thing we need to do is figure out why the
interrogation of the Length property fires off the filter's Read method.

Thanks for your help with this!

- Joseph Geretz -

"bruce barker" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> i'm not sure what your problem is. the filter is a stream, you read the
> stream in, and write it out modified anyway your want. nothing says you
> have to write the same number of bytes you read.
>
> -- bruce (sqlwork.com)
>
>
> Joseph Geretz wrote:
>> I'm using the Request Filter documentation which can be found here:
>>
>> http://msdn.microsoft.com/en-us/libr...st.filter.aspx
>>
>> In this example, two filters are installed, one filter uppercases every
>> alphabetic character and then the second filter replaces every 'E' with
>> "#'. OK, very nice.
>>
>> What's trivial about these examples is that the returned string is
>> exactly the same length as the string which is actually read from the
>> Request stream. I have a slightly more complicated situation where I'm
>> using a Filter to decrypt the data which is pulled from the Request
>> stream. (I'm implementing cryptography in the Filter so that application
>> developers don't need to worry about dealing with this issue; application
>> developers simply retrieve Request data and the filter ensures that it is
>> always delivered in PlainText, regardless of whether it was POSTed in
>> cipher or plain text.)
>>
>> So how do I deal with this issue, where the Request stream contains let's
>> say 2000 bytes, yet the decrypted plaintext is now only 1000 bytes? If I
>> return a count of 1000, then the Read event fires again, seemingly
>> because it appears as though there remains 1000 bytes to remove form the
>> stream. If I return the original count, then the buffer returned is much
>> too large, larger than the actual data which causes problems when
>> attmepting to decrypt the ciphertext. I'f you've ever developed such a
>> scenario, I appreciate any advice which you can provide.
>>
>> Thanks!
>>
>> - Joseph Geretz -



 
Reply With Quote
 
Joseph Geretz
Guest
Posts: n/a
 
      09-03-2008
Some additional diagnostic data:

The following method is functionally the same as the one I presented in my
last post. What I've done though is break down a couple of 'compound'
statements into their components. (Again, I've numbered these for clarity.)

private string zGetRequestBody(HttpContext httpCtx)
{
1. Stream S = httpCtx.Request.InputStream;
2. int Len = (int)S.Length;
3. byte[] buffer = new byte[Len];
4. S.Read(buffer, 0, Len);
5. return Encoding.UTF8.GetString(buffer, 0, Len);
}

What happens now is that statement number 1 is now firing the filter's Read
method (twice), even though this statement is simply the assignment of an
object reference to a variable! This really seems to be at the heart of my
difficulty - the first reference to the Request.InputStream object after the
filter has been wired up results in a double firing of the filter's Read
method. This is bizzarre! Any idea what might account for this?

Thanks for your help!

- Joseph Geretz -

"Joseph Geretz" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi Bruce,
>
> I'm not 100% sure myself what the problem is. I'm seeing a number of
> anomalies. Perhaps you can help me 'peel this onion' to get to the bottom
> of the problem.
>
> In addition to the Request Filter, my application implements an
> HttpModule. The module's purpose in life is basically to wire up the
> Request and Response filters at the start of each transaction. The module
> will also log the request and do certain other application wide
> processing. Here's the code in the HttpModule which attempts to get the
> body of the Request:
>
> (I've numbered these lines just for the clarity of the discussion.)
>
> private string zGetRequestBody(HttpContext httpCtx)
> {
> 1. byte[] buffer = new byte[httpCtx.Request.InputStream.Length];
> 2. httpCtx.Request.InputStream.Read(buffer, 0,
> (int)httpCtx.Request.InputStream.Length);
> 3. return Encoding.UTF8.GetString(buffer, 0, buffer.Length);
> }
>
> The first anomaly I am noticing is that line 1 triggers the *Read* method
> of my Request filter (huh?):
>
> public override int Read(byte[] buffer, int offset, int count)
> {
> int ContentLength;
> ContentLength = m_sink.Read(buffer, offset, count);
> return ContentLength;
> }
>
> (Actually, I observe this method fire twice, for this line of code.)
>
> Now why in the world would this be happening? I've set a breakpoin in the
> Length method, yet this breakpoint is never hit!!
>
> public override long Length
> {
> get { return m_sink.Length; }
> }
>
> So this is my first question on the way to figuring this out: Why does
> httpCtx.Request.InputStream.Length trigger the *Read* method of my filter?
> Shouldn't it be triggering the Length property?? At this point, I've
> completely removed the entire issue of encryption/decryption from the
> excercise. The code I've got in place now works without
> encryption/decryption. but I simply don't understand the mechanics and
> when I add encryption/decryption which dynamically changes the length,
> things go from bad to worse. I suspect that the matter will ultimately
> resolve itself as you suggest, however the first thing we need to do is
> figure out why the interrogation of the Length property fires off the
> filter's Read method.
>
> Thanks for your help with this!
>
> - Joseph Geretz -
>
> "bruce barker" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> i'm not sure what your problem is. the filter is a stream, you read the
>> stream in, and write it out modified anyway your want. nothing says you
>> have to write the same number of bytes you read.
>>
>> -- bruce (sqlwork.com)
>>
>>
>> Joseph Geretz wrote:
>>> I'm using the Request Filter documentation which can be found here:
>>>
>>> http://msdn.microsoft.com/en-us/libr...st.filter.aspx
>>>
>>> In this example, two filters are installed, one filter uppercases every
>>> alphabetic character and then the second filter replaces every 'E' with
>>> "#'. OK, very nice.
>>>
>>> What's trivial about these examples is that the returned string is
>>> exactly the same length as the string which is actually read from the
>>> Request stream. I have a slightly more complicated situation where I'm
>>> using a Filter to decrypt the data which is pulled from the Request
>>> stream. (I'm implementing cryptography in the Filter so that application
>>> developers don't need to worry about dealing with this issue;
>>> application developers simply retrieve Request data and the filter
>>> ensures that it is always delivered in PlainText, regardless of whether
>>> it was POSTed in cipher or plain text.)
>>>
>>> So how do I deal with this issue, where the Request stream contains
>>> let's say 2000 bytes, yet the decrypted plaintext is now only 1000
>>> bytes? If I return a count of 1000, then the Read event fires again,
>>> seemingly because it appears as though there remains 1000 bytes to
>>> remove form the stream. If I return the original count, then the buffer
>>> returned is much too large, larger than the actual data which causes
>>> problems when attmepting to decrypt the ciphertext. I'f you've ever
>>> developed such a scenario, I appreciate any advice which you can
>>> provide.
>>>
>>> Thanks!
>>>
>>> - Joseph Geretz -

>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
a tricky if else(maybe not tricky but impossible) nirkheys@gmail.com C Programming 9 04-25-2006 06:13 PM
tricky jdbc issue Qaran Java 7 05-13-2005 10:36 PM
Tricky Control Validation Issue Mark Sandfox ASP .Net 2 12-15-2004 04:26 PM
Tricky Control Validation Issue Mark Sandfox ASP .Net Web Controls 0 12-15-2004 01:58 AM
HELP: Custom DataReader Function - Tricky issue VB Programmer ASP .Net 4 08-13-2003 03:43 AM



Advertisments