URL newborn timestamp?

Technically only the webserver knows what exact timestamp he first put online an URL.

You're asking about the Date header in HTTP responses from originating servers?

Is it possible from outside without admin access to ask the webserver about this timestamp?

Sure it is. It's done every time. So you're probably asking about something else.

Just make the request. If you get a valid response – a Date header MUST be present … unless it isn't, due to errors and even the absence of reliable system time, or other problems … in which case a Date header may be provided by other sources, such as a caching proxy or even the software that made the request.

It should be enough to do a HEAD request. Or you may be able to finesse things using request headers like If-Modified-Since .

But … Date is specified to be the 'date and time at which the message was originated'. So for non-static resources, Date may change each time you ask, or every time a cached copy has been removed from a cache, and it needs to be regenerated again. Or a proxy in front of the originating web server may have added the Date according to its own ideas. Or … it may change even for static resources, just because the web admin tried to solve some caching problem, and thought that it might be the right way to go.

That is, you can always ask. What you get in response is not useful for anyone except a piece of software that has to do caching decisions. That is, it needn't be true, as long as it works as expected.

If you're not authorized to get a response … you may not get a response you can rely on.

Thank you.

We investigate a case where our external source says that the URL (or URI) was 23 minutes earlier the first time newborn online ever. Its not a problem of UTC/CET timeshift or any timezone wrong interpretation of exact hours plus or minus. The page by hashing is not altered. For sniffing we use HttpWatch chrome extension. For comparison we have an iOS device with the HttpWatch Professional app.

Actually we are 'close' to ask the webserver directly and no more proxy before. But it seems like on purpose code obfuscation. That the webserver based on our IP, NIC MAC or user-agent string lies on us is kind of possible, as with a different approach I cannot reveal we get the true timestamp of 23 minutes earlier as from external confirmed too. No cookies or malware indicates to the webserver our 'getting faulty response approach'.

Sorry, sounds cracy. Can I webserver on purpose technically lie?

If we present the identical request on two ways can a webserver answer differently?

We investigate a case where our external source says that the URL (or URI) was 23 minutes earlier the first time newborn online ever.

Don't understand what that is supposed to mean.

If you know that some particular CMS is used, check its support forums for date/time stamping problems. (If the CMS supports timestamps from 1601 and on , but your web server must provide date stamps from 1970 and on, what happens if some CMS resource gets a timestamp in 1900? A good web server solution detects and handles the problem, and sets date to 1970-01-01. A poor solution assumes everything is OK, and messes up things badly when something unexpected happens…)

If you know that some particular deployment model is used (e.g. developers push data onto a staging server, where things are tested, and QAd, then packaged and moved to one or more production server), check the deployment path for problems. The staging server may not have trusted time, a newbie may have been entrusted with deployment, but made some command line/GUI error, leading to time stamps being restore/not restored …

The only way to be sure is to dig into the general server/CMS/deployment solution, as well as the specific details of the deployment of the particular resource you're referring to.

(I am being very general there may be hundreds of reasons why something else is a better reason, but without details to work on …)

That the webserver based on our IP, NIC MAC or user-agent string lies on us is kind of possible,

In many cases it's bad assumptions about interpretations on the part of investigators (details are often best got from RFCs ), in other cases it's things like … I've seen a web server get Date totally wrong, which turned out to be a web admin who had begun using a web server plugin that gave him control over response headers. He wanted to get rid of Server headers, but for some reason used a full demo config of the plugin that showed off all kinds of header-related stuff in addition to removing Server headers … and he put them all in. He got rid of Server headers, that was all he checked for. But some caching proxies downstreams got the hiccups real bad from all the other things that changed …

If we present the identical request on two ways can a webserver answer differently?

What you ask seems to be a contradiction terms I don't see how identical requests can be done in different ways – that, in my book, makes them non-identical.

It's software, and where's there software Dave is usually lurking, in one form or another.

https://community.spiceworks.com/topic/497931-and-in-this-corner-we-have-dave-funny-cartoon

Yes, it could also be his evil twin James doing something entirely different.

Yes, it could also be his evil twin James doing something entirely different.

But is James an identical or a non-identical twin? ?

wink

jaclaz