Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Let's prove how much better the SharePoint Overflow community is as on Stack Overflow there is a big silence when things become difficult, at least for this question.

I'll omit the wall of text, for full details see this question on Stack Overflow. In summary I have created an HTTPModule based Filter to intercept response streams for binary files so I can modify the content. This is all working fine when the file being requested lives on the server's file system, but if the file is stored in a document library then the data passed to the filter is corrupt. Basically it goes wrong after the first 0 in the stream.

Update 1: Example of corrupt data: Source file : "21 EC 34 00 BA D8". Data that arrives in the write method "21 EC 34 BA BF BF BF BF" (Note how the 00 is removed and data becomes incorrect)

Update 2: I can reproduce the problem on other SharePoint 2007 servers, but on SharePoint 2010 everything works fine.

The relevant code in the HTTPModule for hooking up the filter is as follows:

void context_BeginRequest(object sender, EventArgs e)
{
    HttpContext.Current.Response.Filter = new ResponseFilter(HttpContext.Current.Response.Filter);
}

The implementation of the ResponseFilter Class is as follows. Note that it doesn't actually do anything at the moment other than writing the source data back to the output stream. As the data being passed into the filter is incorrect the resulting output stream is incorrect as well. When the filter is not active, or the file is located outside a Document Library, then it work just fine.

public class ResponseFilter : Stream
{
    private MemoryStream internalStream = new MemoryStream();
    private Stream responseStream;

    public ResponseFilter(Stream outputStream)
    {
        responseStream = outputStream;
    }

    public override void Flush()
    {
        responseStream.Flush();
    }

    public override void Write(byte[] buffer, int offset, int count)
    {
        internalStream.Write(buffer, offset, count);
        responseStream.Write(buffer, offset, count);
    }

    public override void Close()
    {
        responseStream.Close();
    }

    public override bool CanRead
    {
        get { return true; }
    }

    public override bool CanWrite
    {
        get { return true; }
    }

    public override bool CanSeek
    {
        get { return true; }
    }

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

    public override long Position
    {
       get { return internalStream.Position; }
       set { internalStream.Position = value; }
    }

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

    public override long Seek(long offset, SeekOrigin direction)
    {
       return internalStream.Seek(offset, direction);
    }

    public override void SetLength(long length)
    {
       internalStream.SetLength(length);
    }

}

This class is far from perfect, but the problem is that the moment the Write method is hit the data in the buffer is already corrupt. The rest of the class doesn't matter at the moment.

share|improve this question
    
How "Corrupt" is corrupt? Have you had a peek at the data yet - SP might be throwing in versioning, metadata or permissions data along with the file on the way down (no idea if it is or not, just a guess) –  James Love Feb 7 '11 at 10:02
    
The actual 'data' parameter in the 'Write' method already contains the corrupt data and that is the entry point into our logic. It all goes wrong from the moment the source file contains a 0. It is almost like it is treating it as a null terminator for a string. –  Muhimbi Feb 7 '11 at 10:32
    
This is a complicated setup (you have to fold in the SO question also) and I doubt anybody has time to set up such a complex scenario to answer this question. I also doubt there is an "obvious" solution after over six months on both sites. I know you are throwing down the gauntlet but I think it is an unreasonably complex question. Thanks for giving us a shot at this, but I'm voting to close, sorry. –  SPDoctor Aug 10 '11 at 10:46
    
I assume this is being voted to be closed to get the overall percentage of answered questions to go up. I'd say leave it as it is as at some stage someone may run into the same problem as well or we may actually (for once) get a good answer out of Microsoft Support. Complexity should not be a reason to close questions. –  Muhimbi Aug 10 '11 at 12:48
    
In this case, I agree with @SPDoctor... however we should get more input from the community so I won't close it now. I think the challenge is that you are the expert in this situation. :) –  Kit Menke Aug 10 '11 at 14:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.