Fixed PreBodyTagFilter partial writes handling #555
Conversation
|
I've added tests for most cases, but an additional pair of eyes is welcome to see that I did not miss something |
ghost
assigned
|
Just to inform you how I discovered this bug: I added the RawUrl of the request to the warning log when I was investigating some other issue, and after doing that I noticed that I had warning messages for requests for whom Glimpse script tags were injected successfully, which made no sense at all. |
Because currently the logs were not always written due to the asynchronous way of logging by NLog (the AppDomain got unloaded before the writes were done) This also cleans up the HttpModule class for a subsequent PR, because now the extraction of the shutdown message is refactored into its own class.
|
Is this ready to go? If so I will get @nikmd23 to do the once over and see if we can get it in for the next release. Also, are there any other issues (as in github issues) that people have raised that this will fix? |
|
Also WOW on finding the issue and working through the various test cases. Great job! |
|
Lastly just because I know @nikmd23 will ask, why the switchover from the automatic properties to fields? Was it so they could be made readonly? |
|
No other issue has been reported, I noticed this one myself by looking at the Glimpse log while debugging another issue ;-) I added the RawUrl to the log, because I guessed it could help me resolve why I was getting a WARN with regards to the missing I think if people would look at the Glimpse logs, they would see those WARN messages popping up, but without a negative impact on the client (especially in webform environments where viewstate might become quiet large) Anyway, this fix will at least remove some of the false positives we get in other bug reports when we ask for log details... and I will add an issue pointing to this PR so that it gets in the release notes. |
|
With regards to the automatic properties, I was reworking the whole class so I did not paid to much attention to the current uses since I was changing a lot of things. Now on the other hand private automatic properties don't seem to add additional value and you loose indeed something like marking them readonly, which highlights that the fields are really only input and are not supposed to be changed afterwards. But this might lead into some kind of religious debate which has no added value. Are there specific conventions used? Because not all files are formatted the same or apply the same semantics. |
|
Its not documented anywhere but @nikmd23 generally prefers automatic properties and tries not to use the I agree about the logging, but its a pity that the contract needs to be altered to allow the information to be logged. I wonder if there is a better way of allowing cross cutting information to be logged out. |
|
Ah, although a little bit religious, I would be glad to here the reasoning behind that 😉 What do you mean with the following, what contract?
|
|
With the later, you mentioned that you adjusted things to pass through the |
|
I agree, we might be missing some internal IoC container or static accessor to the current Factory of Framework provider instance. But I have to say that I rather see an additional parameter in the constructor of a type then a dependency on some static property which is not directly visible for consuming code. It makes testing a lot harder and brittle as well. |
|
Agreed. On Wed, Oct 16, 2013 at 3:37 AM, Christophe Gijbels <
|
|
|
…itesCorrectly Fixed PreBodyTagFilter partial writes handling
The
PreBodyTagFilterfilter we assign to theResponse.Filterproperty when Glimpse<script...>tags need to be injected, didn't cope well with partial writes. As it seems, it is quite possible that thePreBodyTagFilter.Write(byte[] buffer, int offset, int count)is called multiple times when streaming the output for one request. There seems to be a buffer size of a little bit less than 16K (16352 bytes), which results in outputs of more than 16K to be written in multiple calls to that method.Most of the time this wasn't giving any issues, but there are some specific cases that aren't dealt with properly:
</body>tag could not be found in the first chunks, even though the script injection succeeded because it eventually found a</body>tag in the last chunk. This is now fixed and the warning will only be written when there is effectively no</body>tag found</body>tag (chunk1 ends with</boand chunk2 starts withdy>then Glimpse script tags would not be injected even though the received HTML markup contains a</body>tag. This is now fixed as wellYou could simulate the old situation by simply creating the following controller action, you'll see that Glimpse scripts are not being injected, even though there is a
</body>tag.