How can i serve a locale appropriate .resx file to a http client in ASP.NET?
e.g.
GET /App_LocalResources/MeshModdler.resx
Background
i have a client-side binary that needs to ask a web-server for the appropriate language resources (i.e. it does not have all possible translations; it asks for the one it needs).
Right now the client-side binary prefers to be given an xml file containing all the localized resources (strings, etc). This XML file has a format that looks curiously like Microsoft's resx format (one might think the format was copied - and they would not be wrong).
Ideally we can use the power of an ASP.NET web-server to locate the appropriate resx file based on the http client's Accept-Language, e.g.
GET /App_LocalResources/MeshModdler.resx
Accept-Language: az-Cyrl-AZ
Ideally the web-server would try to return, in order of preference:
MeshModdler.az-Cyrl-AZ.resx
MeshModdler.az-AZ.resx
MeshModdler.az.resx
MeshModdler.resx
But instead the server returns:
HTTP/1.1 404 Not Found
Bonus Chatter
i know this is not possible. So in addition to a cannot be done answer, i would also accept an answer that just does what i want:
harnesses the power of an ASP.NET web-server to perform resource resolution and fallback
allows new localization resx files to be dropped into a folder and have them picked up
will not require resorting to creating a dummy page that builds what looks like a resx file, but has to thunk every entry with:
<root>
<data name="TesselateMesh.Caption">
<value><%$ Resources:MeshModdler, TesselateMesh.Caption1 %></value>
</data>
...
</root>
Additional Chatter
The hack for now will be to rename the resx files to xml:
MeshModdler.az-Cyrl-AZ.xml
MeshModdler.az-AZ.xml
MeshModdler.az.xml
MeshModdler.xml
And re-invent the fallback code:
GET /MeshModdler.az-Cyrl-AZ.xml
404 Not found
GET /MeshModdler.az-AZ.xml
404 Not found
GET /MeshModdler.az.xml
200 Ok
But it would be nice to work with ASP.NET, not against it.
You can create an ASHX file that takes a resource name file and looks up the correct .ResX file on the server. (moving your current fallback logic to /GetResource.ashx?Name=MeshModeler)
Related
I'm using Adobe Content Server (ACS) on our site. I would like to know is it possible in the process of generating GBlink to set filename of the .acsm file?
Right now every .acsm file that users downloaded has name "URLLink.acsm". I found only one mention of this problem on the forum but no solution is suggested. I'll appreciate any help.
This is actually possible and requires to you modify the web.xml file in the fulfillment.war package. If you open the .war package in a program such as 7-Zip, browse to WEB-INF where you can find web.xml. On or around line 110, you'll find this bit of code:
<servlet-mapping>
<servlet-name>URLLink</servlet-name>
<url-pattern>URLLink.acsm</url-pattern>
</servlet-mapping>
You'll want to change it to this:
<servlet-mapping>
<servlet-name>URLLink</servlet-name>
<url-pattern>*.acsm</url-pattern>
</servlet-mapping>
Then in your bookstore you can code URLLink.acsm in the GBLink to be anything you want such as: 'BlahBlahBlah.acsm'.
Unfortunately the only way you can do this is by essentially reverse-proxying the fetching of the ACSM file on behalf of the user - i.e. if you call out to the GBlink yourself, grab the file returned, and then push it on in response to the user's request.
In doing so you will need to set the Content-Type appropriately (application/vnd.adobe.adept+xml), and then you can finally do what you want to do by setting the Content-Disposition header explicitly, to arbitrarily name the file, for example:
Content-Disposition: attachment; filename=mycustomname.acsm
I've ended up doing this in some edge case code, not because I was particularly concerned about arbitrarily naming the file, but because certain mobile browsers, when requesting the GBlink to get the ACSM file directly, would insist on displaying the ACSM XML content directly in the browser. Setting a Content-Disposition: attachment to force download was the only way to solve that, and since Adobe Content Server itself is so inflexible, reverse-proxying the GBlink fetch was really the only way to arbitrarily change the headers on the ACSM response.
Here's what I would like to accomplish:
I have a file stored in Windows Azure Blob Storage (or for that matter any file which is not on my web server but accessible via a URL).
I want to force download a file without actually downloading the file on my web server first i.e. browser should automatically fetch the file from this external URL and prompts the user to download it.
Possible Solutions Explored:
Here's what I have explored so far (and why they won't work):
Using something like FileContentResult as described here Returning a file to View/Download in ASP.NET MVC to download the file. This solution would require me to fetch the contents on my server and then stream from my server to the browser. For this reason this solution won't work.
Using HTML 5 download attribute: HTML 5 download attribute would have worked perfectly fine however the problem is that while it is really a very neat solution, it is not supported in all browsers.
Changing the file's content type: Another thing I could do (at least for the files that I own) to change the content type property of the file to something that the browser wouldn't understand and thus would be forced to download the file. This might work in some browsers however not in all as IE is smart enough to go beyond the content type and sees the file's content to determine the content type. Furthermore if I don't own the files, then I won't have access to changing the content type of the file.
Simply put, in my controller action I should be able to specify the URL of the file and somehow browser should force download the file.
Is this something which can be accomplished? If yes, then any ideas how I could accomplish this?
Simply put, in my controller action I should be able to specify the URL of the file and somehow browser should force download the file [without exposing the URL of the file to the client].
You can't. If the final URL is to remain hidden, your server must serve the data, so your server must download the file from the URL.
Your client can't download a file it can't get the URL to.
You can create file transfer WCF service (REST) which will stream your content from blob storage or from other sources through your file managers to client browser directly by URL.
https://{service}/FileTransfer/DownloadFile/{id, synonym, filename etc}
Blob path won't be exposed, web application will be free from file transfer issues.
When using a cache manifest file within ASP.NET can I just add a standard text file called something like app.manifest? (which is then referenced from the html in each relevant page).
Or are there other considerations (such as mime type) that demand a more convoluted approach?
In this approach: http://stephenwalther.com/blog/archive/2011/01/26/creating-html5-offline-web-applications-with-asp-net.aspx then Stephen Walther sets up the manifest as a handler. Do I really have to do it that way in ASP.NET, or is there a 'simpler' way in ASP.NET? Just striving for less code!
Thanks.
Well, in sighted article, author has created a custom handler to server the manifest with correct MIME type. This is indeed a good way in ASP.NET where you don't have to touch web server configuration.
If you don't want to write such handler and wish to serve file directly such as "app.manifest" then you have to make sure to modify IIS configuration (for the web-site) map the correct MIME Type (text/cache-manifest) for manifest extension (see this and this for how to register a new MIME type in IIS)
I have few settings which I could place in a separate XML file and have them accessed in the Web app. Then I thought (thinking of one additional file to deploy), why not have them in the web.config itself. However, just because I need to have custom nodes, I can not have the settings under . So, I am thinking of creating a custom config handler following this. Would that be better than having a separate XML file? Is It going to be an overkill or performance wise? Is there a better way to go?
From performance standpoint putting custom settings in web.config and creating a configuration handler will be OK because the config values are cached and read only once when the application starts. Putting the values in a separate XML file you will need to handle the caching your self if you want to avoid parsing it every time you need to access those values.
I'm looking to handle image extentions .jpg, .png, .gif, etc. Essentially, what I have is a webserver that takes an image and archives it on the basis of its SHA-1. I use the git convention a1\b2\XXXXXX... with the hex representation of the digest. My question is how is it best to store the extension in the database? Am I safest storing the MIME type? Or, the original file type? Or, should I just auto-generate the MIME each time? Should I store the mime-type the original client sent in the HTTP upload?
As a side note, does IE7+ handle images without file extensions? Is it safe to just send them out without them?
Any other advice on web servers and image types?
Screw the extension. Use libmagic to figure out what it really is and send it out like that. But of course you're going to make sure that the extension matches the file contents in the first place, right?