I'm using a technique similar to Rick Strahls example, but have notcied using google's speed tracer that
Resource Caching : #10.88s - The following resources specify a "Vary" header that disables caching in most versions of Internet Explorer. Fix or remove the "Vary" header for the following resources: ...
The question is Which versions of internet explorer? If I include a way of only outputting Vary for all browsers except early version of internet explorer, will this get resolved?
If AllowsCacheingOnVaryHeader() Then
Response.AppendHeader("Vary", "Content-Encoding")
Response.AppendHeader("Vary", "Accept-Encoding")
End If
In the function "AllowsCacheingOnVaryHeader()" - what exactly should I be checking for? All version of IE prior to 7, 8 or 9?
See EricLaw's for the background on this.
Response.AppendHeader("Vary", "Accept-Encoding")
Should be OK. An up-to-date IE6 should ignore Vary: Accept-Encoding. I believe older IE6 SPs didn't.
Response.AppendHeader("Vary", "Content-Encoding")
I'm not sure what that's for. Content-Encoding is a response header not (typically) a request header so how can you Vary on it? It will certainly trip IE up, can you simply remove that and be done with it?
To answer the question: no, IE7 is still just as broken as IE6 re Vary, as it's using the same underlying wininet code. I haven't tried it but I expect IE8 is the same. IE7 does behave less badly when an ETag is supplied (it revalidates the resource instead of fully refetching it), but the basic bug is unaltered.
Related
I can't seem to find the equivalent of WaitForNonStaleResultsAsOfNow() in RavenDB 4 .NET Client API.
In previous versions this was available through IRavenQueryable.Customize(), but now it contains only WaitForNonStaleResultsAsOf() and WaitForNonStaleResults(). The WaitForNonStaleResultsAsOf() accepts only an ETag and no DateTime.
Also, I tried looking for WaitForNonStaleResultsAsOfLastWrite(), but couldn't find that either. And I couldn't replicate the behaviour myself by using IDocumentStore.GetLastWrittenEtag() since it is not present in 4.0.
Digging around a bit more I found that the last ETag would be available on the Raven.Client.Documents.Operations.DatabaseStatistics-object received as a response of the Raven.Client.Documents.Commands.GetStatisticsCommand... But I can't figure out how to issue this command in 4.0 either :(
Any help on achieving this in RavenDB 4 would be greatly appreciated.
In v4.0 you should only use WaitForNonStaleResults. It will work exactly as the WaitForNonStaleResultsAsOfNow was working. It is asking the server to wait on the query until the currently max etag of all the collections in the query.
Cutoff etag is used to check if the index has already process a
document with the given etag. Unlike Cutoff, which uses dates and is
susceptible to clock synchronization issues between machines, cutoff
etag doesn't rely on both the server and client having a synchronized
clock and can work without it.
WaitForNonStaleResultsAsOf is going to be removed from the client:
http://issues.hibernatingrhinos.com/issue/RavenDB-9678
We had a problem with some of our IE clients failing to download a PDF, even after clicking on the link. We found the answer here resolved our problems: set forcedownload=true for PDF mime types in web.config.
However, that created another problem: we are now unable to render a PDF in a browser when we want to. We used to do this with an iframe. However, as you can see, the PDF just downloads, and does not render in the browser.
I learned that the forcedownload=true setting is actually a default in a subsequent version of Sitecore (v7.2). So, I'm hesitant to revert that.
So, how do I render a PDF in a browser in this situation?
You can leave forceDownload=false on the PDF mime type and instead set the following setting to false:
<setting name="Media.EnableRangeRetrievalRequest" value="false"/>
I faced the same dilema a few months back with the same initial fix. Found out the actual issue last week, I wrote a blog post about it. (In fact, I wrote the answer you linked to, I've updated it with the same information now for future visitors)
The issue is basically a combination of Adobe Reader plugin for IE9, chunked transfer encoding and streaming the file directly from the database. I found if you close your browser and try again, or force refresh with Ctrl+F5 it worked fine. Once Sitecore had cached the file to disk it would continue to work for everyone.
The above setting disables chunked transfer encoding, instead sending the file down to the browser as a single piece. This setting was introduced in Sitecore 6.5+
This is one of the flaws in the MediaRequestHandler and in my opinion; the forceDownload option is pretty useless the way it is designed by default. (Why would ever want to configure this option on media extension only?)
You’ll have to basically turn off the forcedownload option again and replace the MediaRequestHandler with your own one. I usually end up with writing my own anyway because if other issues with the default handler, such as dealing properly with CDN’s etc.
In the ProcessRequest pipeline, you can determine if the item should be “downloaded” or not by setting the Content-Disposition header. You basically need to get rid of the default handling of forceDownload and set your headers based on your own logic.
Personally I prefer to set a query string parameter, such as ?dl=1, and base the Content-Disposition header on this. You could also extend the MediaItem template to contain a default behavior on each item or sub tree (leverage from Sitecore inheritance and standard values), and potentially you could thereby also define (override) a specific filename on each item for the attachment part in the Content-Disposition header.
When rendering the link, you can leverage from the properties collection (write a suitable extension method or similar), so that you can clearly mark your code that the link is meant for download, but still leverage from the built in field render methods. Thereby you eliminate the risk of messing up the page editor etc.
/ Mikael
You have to disable range retrieval request in web.config by setting its value to false.
<setting name="Media.EnableRangeRetrievalRequest" value="false" />
MediaRequestHandler enables Sitecore to download PDF content partially in range using HTTP 206 Status code. You can also overwrite MediaRequestHandler and write your own custom implementation to handle media request.
I'm implementing server push solution.
Is there a way to clear XDomainRequest.responseText of IE8, since it gets filled with the every response chunk?
(to get same effect as in Firefox xhr.responseText with multipart where it contains only the last response part.)
It turns out there is no way to change this behavior.
Check out the comments where former product manager for IE says it's a limitation.
I try to get some info from other sites with xbuf_frurl.
I got some site OK but some Not OK.
By Now, I still can not make sure what is going wrong.
But some sites are missing the content length header.
Who can tell whether xbuf_frurl() relies on the (potentially missing) content length header, esp. when growing the buffer?
xbuf_frurl() is indeed reading a body IF an HTTP content-length header is present. It will not try to decode chunked responses.
To deal with those servers using chunked replies, use the G-WAN curl.c example provided with the distribution. With libcurl you have even the opportunity to use SSL/TLS.
If that's not resolving your problem, the only way to troubleshoot this kind of issues is to give a non-working example, with both the full request that you have sent and the full reply received from the server.
That's why the xbuf_xcat("%v") format has been added: to give hexdumps, even with binary replies.
Edit your question and add this information to let people help you with a well-defined problem.
I see this header appended to the response from apache. Does it have any significance in new age browsers; or it's merely there to circumvent a bug in older versions of Netscape. Seems weird.
EDIT
I was doing a performance testing on our app, when I saw that in Jmeter response text, there was this weird header that comes back. It said:
X-pad: avoid browser bug
Thats it!
So I tried some googling, and it seemed like a header added for Netscape browsers' bug. Anyway, I am still curious, that since we are so far away from those versions of browser (thankfully), is there a solid reason that it's still there.
We use apache2.
Hopefully those details help.
Cheers
Nope, it's a vestigial header nowadays; that is to say, it was put there to work around a bug in a browser which is obsolete (several generations older than IE6 - the bug was reported fixed as of 1997, 15 years ago!) and nobody uses it any more.
The patch to remove it is in Apache's SVN since 2008, but it apparently still hasn't propagated to all distributions (plus some sites may use non-updated versions of Apache).
Here's the comment for the header, picked up from the source:
/* Navigator versions 2.x, 3.x and 4.0 betas up to and including 4.0b2
* have a header parsing bug. If the terminating \r\n occur starting
* at offset 256, 257 or 258 of output then it will not properly parse
* the headers. Curiously it doesn't exhibit this problem at 512, 513.
* We are guessing that this is because their initial read of a new request
* uses a 256 byte buffer, and subsequent reads use a larger buffer.
* So the problem might exist at different offsets as well.
*
* This should also work on keepalive connections assuming they use the
* same small buffer for the first read of each new request.
*
* At any rate, we check the bytes written so far and, if we are about to
* tickle the bug, we instead insert a bogus padding header. Since the bug
* manifests as a broken image in Navigator, users blame the server. :(
* It is more expensive to check the User-Agent than it is to just add the
* bytes, so we haven't used the BrowserMatch feature here.
*/
I know that the answer has been accepted but still I think this would be useful for users running php.
If you're a php user and you're getting this header. You can turn it off using custom "X-Powered-By" header. For Example:
header('X-Powered-By: Powerful Management'); you can also remove it this way
header_remove('X-Pad');, sometimes setting that header to empty also removes it:
header('X-Pad:')
and bam your X-Pad header will disappear