I have a file "/index.html" that includes "/news.html". I make edits to "/index.html" at 9 AM. I make edits to "/news.html" at 10 AM. If I curl "/index.html" (through Varnish 4) should I expect to see Last-Modified header value reflect 9 AM or 10 AM?
(I'd hope for Last-Modified to reflect 10 AM but I'm not seeing that happen. Varnish 4, caching enabled)
Maybe not a definitive answer but here are my thoughts:
I presume you are using esi:include to include the news.html file into the index.html file.
Because I think the esi:include is "lazily" evaluated I would still expect to see the changes made to news.html at 10 AM to be reflected in a call made to index.html after [10 AM + the caching time of news.html].
I guess the Last-Modified Header shows 9 AM because this it the time the index.html file was last changed and this is the response header the backend system provides Varnish with. Varnish simply forwards this to the client.
It does not seem that Varnish is "merging" the values of the Last-Modified Header of the main resource and the esi:includes and using the latest one - which might make sense.
Related
I have a node app (specifically sails app) that is serving pdf file. My code for serving file looks like this.
request.get(pdfUrl).pipe(res)
And when I view the url for pdf, it renders the pdf fine. But sometimes, it just renders the binary data of pdf on browser like given below.
%PDF-1.4 1 0 obj << /Title (��) /Creator (��wkhtmltopdf
I am not able to figure out why is it failing to serve the pdf correctly just randomly. Is it chrome thing? or Am I missing something?
Leaving this here in the hope that it helps somebody - I have had similar issues multiple times and its either of two things:
You're using an HTTP connection to an HTTPS delivery (this is typical with websockets, where you must specify :443 in addition to the wss.
request's encoding parameter is serving plaintext instead of objects. This is done by setting encoding to null as follows: request({url: myUrl, encoding: null}).
Content types in headers - steering clear of this since it's obvious/others have covered this substantially enough already :)
I am pretty sure you're facing this due to (2). Have a look at https://github.com/request/request
encoding - Encoding to be used on setEncoding of response data. If
null, the body is returned as a Buffer. Anything else (including the
default value of undefined) will be passed as the encoding parameter
to toString() (meaning this is effectively utf8 by default). (Note: if
you expect binary data, you should set encoding: null.)
Since, the aforementioned suggestions didn't work for you, would like to see forensics from the following:
Are files that fail over a particular size? Is this a buffer issue at some level?
Does the presence of a certain character in the file cause this because it breaks some of your script?
Are the meta-data sections and file-endings the same across a failed and a successful file? How any media file is signed up-top, and how it's truncated down-bottom, can greatly impact how it is interpreted
You may need to include the content type header application/pdf in the node response to tell the recipient that what they're receiving is a PDF. Some browsers are smart enough to determine the content type from the data stream, but you can't assume that's always the case.
When Chrome downloads the PDF as text I would check the very end of the file. The PDF file contains the obligatory xref table at the end. So every valid PDF file should end with the following sequence: %EOF. If not then the request was interrupted or something gone wrong.
You also need HTTP header:
Content-Disposition:inline; filename=sample.pdf;
And
Content-Length: 200
Did you try to save what ever binary stuff you get on disk and open it manually by PDF reader? It could be corrupt.
I would suggest trying both of these:
Content-Type: application/pdf
Content-Disposition: attachment; filename="somefilename.pdf"
(or controlling Mime Type in other ways: https://www.npmjs.com/package/mime-types)
I'm trying to set X-Delete-After and X-Delete-At to a file i'm uploading.
So i tired :
FileMetaData.Add("X-Delete-After", "30");
cloudFilesProvider.UpdateObjectMetadata(inStrContainerID, strDesFileName, FileMetaData);
but the header did not get recognized.
is that the right approach?
Edit: I'm trying to use ICloudFilesMetadataProcessor.ProcessMetadata, but really have no clue how to and am not able to find any documentation.
In the current release of the SDK, you can include the X-Delete-After or X-Delete-At value in the headers argument to the following calls:
IObjectStorageProvider.CreateObject
IObjectStorageProvider.CreateObjectFromFile
Currently there is no way in the SDK to change the value of this header after the file has already been uploaded (e.g. using UpdateObjectMetadata as you suggest in the question would set the values X-Object-Meta-X-Delete-After or X-Object-Meta-X-Delete-After, which is not correct).
Here is a related issue on GitHub:
#167: How to assign version folder
Gopstar --
EDITED:
After more investigation; I set the X-Delete-After to 1500 and the code worked. Sort of. When viewing the file header information via the dashboard, the X-Delete-At was set.
However, the result was correct; the X-Delete-At was equal to what would be 1500 seconds from the time I set it.
Original reply:
I played around; if you set the value higher (for example, I tried X-Delete-After = 3000) it will work.
I do NOT know the lowest number acceptable, but I'm sure someone will chime in with the number.
Hope this give SOME help.
Directory contains about a dozen html files. Index.html contains links to all the others.
Same directory contains hundreds of Word files. HTML files contain links to the Word files.
All links are relative, i.e., no protocol, no host, no path, and no slash.
Click on a link to an HTML file, it works. Click on a link to a word doc, browser says it can't be found. To get more precise on the error, I used wget
Oversimplified version:
wget "http://Lang-Learn.us/RTR/Immigration.html"
gives me the file I asked for, but
wget "http://Lang-Learn.us/RTR/Al otro lado.doc"
tells me that Lang-Learn.us doesn't exist (400)
Same results if I use "lang-learn.us" instead. I did verify correct casing on the filenames themselves, and also tried escaping the spaces with %20 (didn't help, not that I expected it to after the host name message).
The actual session:
MBP:~ wgroleau$ wget "http://Lang-Learn.us/RTR/Immigration.html"
--2011-03-09 00:39:51-- http://lang-learn.us/RTR/Immigration.html
Resolving lang-learn.us... 208.109.14.87
Connecting to lang-learn.us|208.109.14.87|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `Immigration.html.2'
[ <=>
] 5,973 --.-K/s in 0s
2011-03-09 00:39:51 (190 MB/s) - `Immigration.html.2' saved [5973]
MBP:~ wgroleau$ wget "http://Lang-Learn.us/RTR/Al otro lado.doc"
--2011-03-09 00:40:11-- http://lang-learn.us/RTR/Al%20otro%20lado.doc
Resolving lang-learn.us... 208.109.14.87
Connecting to lang-learn.us|208.109.14.87|:80... connected.
HTTP request sent, awaiting response... 400 No Host matches server name lang-learn.us
2011-03-09 00:40:11 ERROR 400: No Host matches server name lang-learn.us.
The error looks like an issue with redirection or domain mapping,
but how could that be turned on or off by the file extension?
The hosting provider at first tried to tell me I don't know how to write HTML, but when I mentioned I've been in software for thirty years and web work for several, he put me on hold to find someone that actually knows something. Eventually they came back and said it's MY fault for not having the correct stuff in .htaccess
Setting aside the obvious retort about it being the hosting provider's job to put the correct stuff in httpd.conf, I made a couple of attempts. But 99% of my web work has been content in HTML/PHP/perl and I know nearly nothing about .htaccess
The following two attempts did NOT work:
AddType application/msword .doc
AddType application/octet-stream .doc
UPDATE: By using
<FilesMatch "\.html$">
ForceType application/octet-stream
</FilesMatch>
I verified that the server does allow .htaccess, but using .doc instead of HTML still gets that idiotic "ERROR 400: No Host matches server name lang-learn.us"
Finally, after hours with more than one "tech supporter," I got them to admit that they had made a configuration error. Besides telling me to use .htaccess, they had an earlier suggestion that I ask the client to convert his hundreds of Word files into HTML pages.
Since the provider is the one that screwed up, there technically is no answer to the question of what can I do to fix it.
I building my sites on the localhost (runs wamp on windows), and when I upload it to my server, I always get
"Cannot modify header information - headers already sent"
I understand that there shouldn't be any blank lines and everyhing, and usually this works out. but now I need to redirect someone after the header has been sent, how can I make my server act like my localhost ?
i'm using cpanel and WHM:
cPanel 11.25.0-R42399 - WHM 11.25.0 - X 3.9
CENTOS 5.4 x86_64 virtuozzo on vps
I will appreciate any help
In short, you need to prevent PHP from outputting anything to the browser before you get to the point where you want to use the header() function.
This should be done by careful programming practices, of which your 'no blank lines' is one, or by storing PHP's output in an output buffer, and only outputting when you're ready for it.
See the ob_start() and ob_flush() methods. You use ob_start() at the start of your application. This disables output and stores it into a buffer. When you're ready to start outputting, use ob_flush() and PHP will send the buffer's contents to the browser, including the headers that are set till that point. If you don't call ob_flush() then the buffer is output (flushed) at the end of the script.
The reason why it works on your WAMP development environment is most likely that output buffering is already enable by default in the php.ini. Quite often these all-in-one packages enable a default buffer for the first 4k bytes or so. However, it is generally better to explicitly start and flush the buffer in your code, since that forces better coding practices.
Well,
I guess by more thinking and better programing you can manage to keep all redirects before any HTML is written.
This problem solved by the old rules...
#user31279: The quickest and dirtiest way I know of is to use # to suppress the warning, so e.g.
#header('Location: some-other-page.php');
im using httpclient and last-modified header in order to retrieve the last updated date of an html file however when i try this on a linux box it returns yesterdays date but when i use a windows machine it returns todays date. is anyone aware of issues using this header field in linux?
Perhaps, linux server has its clock set differently and this way "lives in the past"?
If you dualboot with Windows, you must make sure your Linux system is configured to not think the BIOS keeps the clock in GMT (or UTC), but in local time. Otherwise your Linux system's clock will keep being off when in Linux.
Also make sure that the /etc/localtime file is a symlink to the correct time zone file under /usr/share/zoneinfo.
After configuring those two things, verify your date and time is correct using the date command and set it correctly if it isn't, via:
date MMDDhhmmCCYY.ss
For example, for the current time at my end (19:41:27 on October 15th 2008) I would use:
date 101519412008.27
Just a thought - perhaps your filesystem was mounted with the noatime option. I'm making the assumption here that your html file wasn't modified, only accessed without changes and the 'updated' time wasn't recorded.
Can you see the timestamp of the file? Is it exactly 1 day out, or just sometime yesterday?
when i look at the date assocaiated with the time it is correct, but then the date that gets displayed after i call the http method is one day behind. Possibly a problem with caching