production vs dev server content-disposition filename encoding - asp.net-mvc-3

I am using asp.net mvc3, download file in the same browser (Chrome 22). Here is the controller code:
[HttpPost]
public ActionResult Uploadfile(HttpPostedFileBase file)//HttpPostedFileBase file, string excelSumInfoId)
{
...
return File(
result.Output,
"application/vnd.ms-excel",
String.Format("{0}_{1:yyyy.MM.dd-HH.mm.ss}.xls", "Суммирование", DateTime.Now));
}
On my dev machine I download a programmatically created file with the correct name "Суммирование_2012.10.18-13.36.06.xls".
Response:
Content-Disposition:attachment; filename*=UTF-8''%D0%A1%D1%83%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_2012.10.18-13.36.06.xls
Content-Length:203776
Content-Type:application/vnd.ms-excel
Date:Thu, 18 Oct 2012 09:36:06 GMT
Server:ASP.NET Development Server/10.0.0.0
X-AspNet-Version:4.0.30319
X-AspNetMvc-Version:3.0
And from production server I download a file with the name of the controller's action + correct extension "Uploadfile.xls", which is wrong.
Response:
Content-Disposition:attachment; filename="=?utf-8?B?0KHRg9C80LzQuNGA0L7QstCw0L3QuNC1XzIwMTIuMTAuMTgtMTMuMzYu?=%0d%0a =?utf-8?B?NTUueGxz?="
Content-Length:203776
Content-Type:application/vnd.ms-excel
Date:Thu, 18 Oct 2012 09:36:55 GMT
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-AspNetMvc-Version:3.0
X-Powered-By:ASP.NET
Web.config files are the same on both machines.
Why does filename gets encoded differently for the same browser? Are there any kinds of default settings in web.config that are different on machines that I am missing?

The dev server is running .NET 4, and the production server is running .NET 4.5. The MVC framework contains a heuristic for determining whether it needs to use RFC 6266 for the Content-Disposition header, and while this heuristic works correctly on .NET 4 it does not work correctly on .NET 4.5. The end result is that the Content-Disposition header gets mangled, as you're witnessing in this instance.
Your easiest course of action would probably be to upgrade the application to MVC 4. That version of the framework contains a different heuristic that is more robust and should work correctly on both .NET 4 and .NET 4.5.

Most likely reason seems to be that the server indeed sees different User-Agent header fields.
That being said, the 2nd response isn't correct for any browser, and you should report that problem to Microsoft.

Related

Azure.Storage.Blobs support for localDevelopment throws The value for one of the HTTP headers is not in the correct format

I am trying get past some unit test after upgrading from Microsoft.Azure.Blob to Azure.Storage.Blobs. My connection to BlobServiceClient is
// create service client:
var blobServiceClient = BlobServiceClient("UseDevelopmentStorage=true")
//create container
BlobContainerClient container = client.GetBlobContainerClient(containerName);
//my code blows up on 'container.exists()'...but I don't get read access error.
//RequestFailedException : "The value for one of the HTTP headers is not in the correct format."
if(!container.Exists())
container = client.CreateBlobContainer(containerName).Value;
BlobClient blobClient = container.GetBlobClient($"{blobName}.json");
await blobClient.UploadAsync(BinaryData.FromString(jsonContent), options);
Wondering if anyone knows if there is some limitation on using azurite and the latest libs?
checking my container it 'looks' to me like it is ok? I have tried using the provided connection strings from within Microsoft Azure Storage explorer as well and had the same issues. I can't understand what it means by my headers are incorrect. The other answers are related to functions and also gt 4 years old. I feel like this issue is something to do with my unit test setup.
The actual error message:
The value for one of the HTTP headers is not in the correct format.
RequestId:5b9f9072-606b-4dfa-b174-19ef2fa2c20d
Time:2023-01-27T00:02:23.357Z
Status: 400 (The value for one of the HTTP headers is not in the correct format.)
ErrorCode: InvalidHeaderValue
Additional Information:
HeaderName: x-ms-version
HeaderValue: 2021-10-04
Content:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Error>
<Code>InvalidHeaderValue</Code>
<Message>The value for one of the HTTP headers is not in the correct format.
RequestId:5b9f9072-606b-4dfa-b174-19ef2fa2c20d
Time:2023-01-27T00:02:23.357Z</Message>
<HeaderName>x-ms-version</HeaderName>
<HeaderValue>2021-10-04</HeaderValue>
</Error>
Headers:
Server: Azurite-Blob/3.17.1
x-ms-error-code: InvalidHeaderValue
x-ms-request-id: 5b9f9072-606b-4dfa-b174-19ef2fa2c20d
Date: Fri, 27 Jan 2023 00:02:23 GMT
Connection: keep-alive
Keep-Alive: REDACTED
Transfer-Encoding: chunked
Content-Type: application/xml
The error is happening because the Storage REST API version supported by your installation of Azurite (v3.17.1) is not the latest REST API version which is supported by the version of SDK (12.14.1) you are using.
To fix this issue, there are a few options:
Update your installation of Azurite to the latest version. Looking at Azurite releases, REST API version 2021-10-04 support is included in version 3.19.0.
Use cloud storage for development if possible. That way you will not run into these versioning issues.
Though not recommended but if you want to keep on using version 3.17.1 of Azurite, you would need to downgrade the SDK to a version that has support for the same REST API version.

Download fails, is it wrong with the keep-alive?

Downloading a file directly (without any scripts) from the server, sometimes it fails for slow internet connections.
e,g for any file, each time users can download some percent of the file. And sometimes they can download it completely.
In the cases that download fails, browser doesn't show a "Failed" text. it seems the file has been downloaded completely.
I thought it might be with the keep-alive connection. I use these response headers:
Accept-Ranges:bytes
Cache-Control:max-age=172800
Connection:Keep-Alive
Content-Length:36195412
Content-Type:application/x-rar-compressed
Date:Tue, 28 Jul 2015 07:00:49 GMT
ETag:"a9825a8-2284c54-518bca9ddaaad"
Expires:Thu, 30 Jul 2015 07:00:49 GMT
Keep-Alive:timeout=5
Last-Modified:Wed, 17 Jun 2015 20:37:46 GMT
Server:Apache/2.4.12
Vary:User-Agent
And one more question.You can see in the headers that keep-alive is set like this: keep-alive:timeout=5 there is no max here. so is it default to 0 or something else?
Thanks.
Well, I figured out that it is not related to keep-alive. I and most of our clients were using proxies, it made some problems.

Caching-Headers for Images are always "no-cache" and "expires: -1"

I'm running a Piranha CMS based page, using it as a content source in passive mode.
While working on optimizing pagespeed i saw that all image requests handled by piranha return the following response headers:
GET /media/4b3b3fa3-ff7b-4af7-81f2-168474edd23f/50/20
Cache-Control:no-cache
Content-Length:52826
Content-Type:image/jpeg
Date:Mon, 17 Nov 2014 11:53:28 GMT
Expires:-1
Pragma:no-cache
X-UA-Compatible:IE=Edge,chrome=1
Naturally, i want these images to be cached where possible.
I looked around the code on github and saw that this information appears to be set in /Piranha/Web/ClientCache.cs.
Is there a way to influence the caching headers set by piranha?
The configuration section isn't all that clear in the current version but the caching is controlled by two parameters that you can set in the manager interface from System > Parameters. Here you have the two parameters CACHE_PUBLIC_EXPIRES and CACHE_PUBLIC_MAXAGE which specifies the time, in minutes, of the client browser cache.
These are set to 0 by default since you don't want cache enabled during development which disables the cache and renders the no-cache headers. When you activate the cache E-tag, Last modified & Expires headers will be generated for your media files.
Best regards
Håkan

Browser behavior when no cache-control policy header defined

I'm trying to improve the caching policy for a web site.
I'm implementing an aggressive caching strategy first, for resources that won't change at all, and would like files like jquery-min for example to be downloaded only once, and then be served from browser cache.
I used Apache Mod-Expire module to accomplish this, and it's working pretty well.
However, I'm surprised that when I completely remove my cache-control configuration, Firefox browser does not re-download jquery file : it already gets it from the cache, without any instruction from me. How is Firefox making this kind of decision ? Is it related to the ETag hash ?
Here are the headers I get without my configuration for that particular file :
Accept-Ranges bytes
Connection Keep-Alive
Content-Encoding gzip
Content-Length 27073
Content-Type application/javascript
Date Fri, 23 Aug 2013 09:48:06 GMT
Etag "225f8-13309-4e385823c7b80"
Keep-Alive timeout=15, max=99
Last-Modified Fri, 09 Aug 2013 15:34:22 GMT
Server Apache
Vary Accept-Encoding
Can anyone explain to me what is the browser behavior when there's no Cache-Control policy defined ? is it browser dependant ?
Thank you,
Mathieu.

Why Plone 3 sets language cookie to CSS & JS registry files and how to get rid off it?

Plone 3.3.5, LinguaPlone and Products.CacheSetup installed.
Language cookie set for portal_css and portal_javascript files
HTTP/1.1 200 OK
Server: Zope/(unreleased version, python 2.4.5, linux2) ZServer/1.1 Plone/3.3.5
Expires: Tue, 26 Apr 2011 10:42:56 GMT
Last-Modified: Tue, 19 Apr 2011 10:42:56 GMT
Cache-Control: max-age=604800
Content-Type: application/x-javascript;charset=utf-8
Set-Cookie: I18N_LANGUAGE="en"; Path=/
Content-Length: 192404
Date: Tue, 19 Apr 2011 10:42:56 GMT
X-Varnish: 452768899
Age: 0
Via: 1.1 varnish
Connection: keep-alive
Pituus: 192404 (188K) [application/x-javascript]
Tallennetaan kohteeseen ”tiny_mce-cachekey1974.js”
This prevents caching. I found some old information related to this:
http://www.evax.fr/papers/nginx-varnish-and-multilingual-plone
1) Why it is set? I assume all resources are language neutral by default and only in special conditions contain language specific stuff.
2) How do I get rid off it? Maybe there is a smarter way than monkey-patching, but not documented anywhere.
3) Any changes related to this in Plone 4.x?
The cookie is set by the LanguageTool, and is only set when not present yet in the request, or different from what was set in the request.
The LanguageTool normally would only look at that very cookie for deciding what language to use. In normal Plone use therefor, you will never see that Set-Cookie header on CSS and JS resources. LinguaPlone however, configures the LanguageTool to look at a lot more information, including the URL you were trying to access, to determine a language to use for the response.
With LinguaPlone installed, what the LanguageTool does is to determine the correct language for every resource accessed, as that is the only way to ensure a consistent UI language through-out.
The cookie is normally already set on load of the main page (which subsequently loads JS and CSS with the cookie set). Thus, in the normal scenario your CSS and JS are perfectly cacheable. You are only seeing the Set-Cookie header because there is no corresponding Cookie: I18N_LANGUAGE="en" header in the request.
If you have to control this for your specific use-cases, you could monkeypatch Products.PloneLanguageTool.LanguageTool.LanguageTool.__call__, which is a before-publishing-traverse hook that will trigger the language determination on every request. I'd recommend using collective.monkeypatcher for this. Here is what I did in a recent project where the site was migrated with a mixed set of languages throughout the tree (something we'll have to untangle at some point in the future):
configure.zcml:
<?xml version="1.0"?>
<configure
xmlns="http://namespaces.zope.org/zope"
xmlns:monkey="http://namespaces.plone.org/monkey"
>
<!-- other directives -->
<include package="collective.monkeypatcher" />
<monkey:patch
description="Patch LanguageTool before traverse hook to prevent setting
the language cookie"
class="Products.PloneLanguageTool.LanguageTool.LanguageTool"
original="__call__"
replacement=".patches.LanguageTool__call__"
preserveOriginal="true"
/>
</configure>
and in the patches.py module:
from ZPublisher.HTTPRequest import HTTPRequest
def LanguageTool__call__(self, container, req):
"""The __before_publishing_traverse__ hook.
Patched to *not* set the language cookie, as this breaks the site model.
"""
self._old___call__(container, req)
if not isinstance(req, HTTPRequest):
return None
response = req.response
if 'I18N_LANGUAGE' in response.cookies:
if 'set_language' in req.form:
return None
del response.cookies['I18N_LANGUAGE']
Note that the patch deletes the cookie after the fact, unless set_language was used on the current request.
There are no changes pending for this behaviour for Plone 4.x.

Resources