in Struts2 it is possible to serve static content like images, JS or CSS files by putting them into resources/static. From this point Struts2 takes care for serving them on HTTP request and everyone, especially my JSPs, are happy.
Now I have to retrieve all this static files from a DB; I get them as byte[]. The purpose is to exchange the files without redeploying the web application.
Do you have any suggestions how to serve them elegantly?
Can I overwrite e.g. some static resource provider? Alternatively, should I provide an action for that?
I'm mainly concerned about caching. Is there something else I should be concerned about?
Thanks in advance, any hint is appreciated! :)
Gregor
Create an action to fetch the data from the database and then use the stream result type. The stream result will automatically handle setting the appropriate cache headers for the response (caching is turned on by default). You will need to provide the content type and the InputStream.
For details, check the Javadoc for StreamResult.
Related
I have been using response templating to give dynamic responses, given that all the request and query parameters are associated with that request itself. However, I wanted to make a POST request with several parameters, and later use those parameters in a stubbed GET method's body response by using response templating. Is this something possible to do in wiremock? Any input is greatly appreciated, thank you!
Storing state between requests is not a default feature of WireMock outside of mocking the behavior through Stateful Behaviour, which is different from being actually stateful.
Without a custom plugin being able to share information between several requests is therefor not possible. In the WireMock documentation there is a section in the documentation on how to create such a plugin yourself. With a little development experience this is certainly doable.
On GitHub there are several plugin that create a storage mechanism to store information
WireMockCsv: store and retrieve information using HSQL Database.
wiremock-redis-extension does something similar using Redis.
An alternative to these approaches is to create mappings/data just before the test starts. For example generating all the responses beforehand and then using Templated BodyFileName tag to retrieve the just-in-time created file. Another way of achieving this result is to use the Admin API to create the mappings themselves directly.
Im migrating a site from using http to redirect all requests to https and therefor im making sure external script, images etc are references with just // in the beginning of the url instead of http://
My question is this. Do i also need to change stuff like the xhtml namespaces for the html tag or the doctype declaration url? And if I do need to change this, will they resolve urls starting with //?
Namespaces are identifying strings that happen to use URL syntax. They should not be changed.
The DTD is a tricky one.
In theory, if it was altered with a man-in-the-middle attack, then it could be used to change named entities and insert new content into the document.
In practise however, browsers don't generally parse the DTD so this isn't really a worry. Additionally, W3C DTDs are not served over HTTPS so you can't reference them without copying the files to your own server (and possibly updating internal references). If you want to be really safe, you should do this.
Personally, I'd scrap DTDs and just use (X)HTML 5.
Let me try to explain by example. Say website is hosted at example.com (NOT www.example.com). In order to serve static content cookie-free, I've chosen to use a different domain example-static.com.
Now, lets consider that my static content is currently served like this:
http://example.com/js/script.js
http://example.com/css/style.css
http://example.com/media/image.jpg
** Now I create a CNAME record aliasing example-static.com to my main domain i.e. example.com so that the static content is served as such:
http://example-static.com/js/script.js
http://example-static.com/css/style.css
http://example-static.com/media/image.jpg
** Is that all I have to do? Will all browsers execute JavaScript files and load web fonts without any security concerns? OR should I be using some .htaccess rules to modify header information and the like?
PS: It would be great if you can provide what rules should be added, if need be.
EDIT: The reason why I added a bounty to this question is that people I know have advised me against serving JS from a different domain. They aren't able to give me a clear explanation either.
It will work without extra config. However: does it worth the pain? If you use some real content delivery network that's fine, but simply faking one, to be cookie-free? A much better approach would be to minimize cookie size IMHO.
Gergely's answer answers my question. And I've also found an alternative. Since my website is served from example.com, instead of serving static content from a different domain, I am planning to serve the cookies themselves from a different sub-domain www.example.com.
Simple, and should do the job.
I've written a REST server in Delphi XE (using the wizard) and I want to change the URLs a bit so that instead of having
http://192.168.1.84:8080/datasnap/rest/TServerMethods1/GetListings
I get something that looks more like http://192.168.1.84:8080/GetListings
Is there a nice easy of doing this?
The naming convention is (Delphi XE3):
http://my.site.com/datasnap/rest/URIClassName/URIMethodName[/inputParameter]
You can easily change the "datasnap" and "rest" part of the URL in the TDSHTTPWebDispatcher component properties. You can change the Class Name and Method Name of the URL by simply changing the name of your class and method. However, you still have to have 4 components to the URL, so for example it could be:
http://my.site.com/api/v1/People/Listing
See here:
http://docwiki.embarcadero.com/RADStudio/XE3/en/REST#Customizing_the_URL_for_REST_requests
You could put IIS or Apache in between to accomplish this, and indeed rewrite the URL to point to your service the way you like.
That provides some more advantages anyway (security and scalability mostly). For example, you can create a fail-safe setup with double servers, or you can create multiple machines with your service, and have your web server do the load balancing for example.
You'll get extra logging capabilities, and if you easily want to serve other web content it's easy to have a full fledged web server anyway.
URL rewriting is usually done in the web server configuration, in Apache using entries in the .htaccess file
The tutorials I'm reading say to do that, but none of the websites I use do it. Why not?
none of the websites I use [put .htm into urls] Why not?
The simple answer would be:
Most sites offer dynamic content instead of static html pages.
Longer answer:
The file extension doesn't matter. It's all about the web server configuration.
Web server checks the extension of the file, then it knows how to handle it (send .html straight to client, run .php through mod_php and generate a html page etc.) This is configurable.
Then web server sends the content (static or generated) to the client, and the http protocol includes telling the client the type of the content in the headers before the web page is sent.
By the way, .htm is no longer needed. We don't use DOS with 8.3 filenames anymore.
To make it even more complicated: :-)
Web server can do url rewriting. For example it could redirect all urls of form : www.foo.com/photos/[imagename] to actual script located in www.foo.com/imgview.php?image=[imagename]
The .htm extension is an abomination left over from the days of 8.3 file name length limitations. If you're writing HTML, its more properly stored in a .html file. Bear in mind that a URL that you see in your browser doesn't necessarily correspond directly to some file on the server, which is why you rarely see .html or .htm in anything other than static sites.
I presume you're reading tutorials on creating static html web pages. Most sites are dynamically generated from programs that use the url to determine the content you see. The url is not tied to a file. If no such dynamic programs are present, then files are urls are synonomous.
If you can, leave off the .htm (or any file extension). It adds nothing to the use of the site, and exposes an irrelevant detail in the URL.
There's no need to put .htm in your URL's. Not only does it expose an unnecessary backend detail about your site, it also means that there is less room in your URLs for other characters.
It's true that URL's can be insanely long... but if you email a long link, it will often break. Not everyone uses TinyURL and the like, so it makes sense to keep your URL's short enough so that they don't get truncated in emails. Those four characters (.htm) might make the difference between your emailed url getting truncated or not!