There's a way to change timezone in response body using curl (CEST instead of GMT)?
E.G.
curl -v http://ip-api.com/line?fields=timezone
Trying 10.247.129.103... connected
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
**< Date: Mon, 12 Oct 2020 10:38:06 GMT**
Europe/Rome
Server TZ is :
cat /etc/sysconfig/clock
# The time zone of the system is defined by the contents of /etc/localtime.
# This file is only for evaluation by system-config-date, do not rely on its
# contents elsewhere.
ZONE="Europe/Rome"
Thanks in advance.
You seem to be asking about the Date in the HTTP response. It's a header - not in the response body.
This header has nothing to do with cURL. It's the standard HTTP Date header, that every HTTP server must include in its response. It's defined in RFC 7231 Section 7.1.1, and it must always be in terms of GMT.
This particular website you are calling is using a geolocation technique to resolve an approximate IANA time zone identifier (Europe/Rome in your example) from the caller's IP address. You can take this identifier and use it in your own logic to resolve the current time in that time zone. For example, after your cURL call, assuming you are using a Linux distribution that has a tzdata package installed (which most do), you can set the TZ environment variable and use the date command like this:
TZ=Europe/Rome date
Example output:
Mon Oct 12 18:50:04 CEST 2020
There are plenty of other ways you can use the time zone in different programming languages and environments, so choose an approach that works for your use case.
Related
I am using wordpress. I deploy Varnish Using Docker. This Is My default.vcl. What's Wrong With This Config?? Sometimes, Get Random 503 Error. I Exclude Wordpress Search Page Using RegEx. Also Get Random 503 Error On wordpress Search Page Too!!
varnishlog
https://www.dropbox.com/s/ruczg2i3h/log.txt
I am Using NGINX Backened..
Help Appreciated
Thanks
Your log output contains the following lines:
- Error out of workspace (bo)
- LostHeader Date:
- BerespHeader Server: Varnish
- VCL_call BACKEND_ERROR
- LostHeader Content-Type:
- LostHeader Retry-After:
Apparently you ran out of workspace memory because the size of the response.
The following parameters in your Docker config might cause that:
-p http_resp_hdr_len=65536 \
-p http_resp_size=98304 \
While increasing the size of individual headers and the total response size, the total memory consumption exceeds the workspace_backend value, which defaults to 64k.
Here's the documentation for http_resp_size:
$ varnishadm param.show http_resp_size
http_resp_size
Value is: 32k [bytes] (default)
Minimum is: 0.25k
Maximum number of bytes of HTTP backend response we will deal
with. This is a limit on all bytes up to the double blank line
which ends the HTTP response.
The memory for the response is allocated from the backend
workspace (param: workspace_backend) and this parameter limits
how much of that the response is allowed to take up.
As you can see, it affects workspace_backend. So here's the documentation for that:
$ varnishadm param.show workspace_backend
workspace_backend
Value is: 64k [bytes] (default)
Minimum is: 1k
Bytes of HTTP protocol workspace for backend HTTP req/resp. If
larger than 4k, use a multiple of 4k for VM efficiency.
NB: This parameter may take quite some time to take (full)
effect.
The solution is to increase the workspace_backend through a -p runtime parameter.
This is the code that provides the error, along with the output from it.
I'm positive my access keys and tokens are correct. I triple checked them.
I'm guessing my query may be wrong somehow? My guess was defaulting since_id=0 for my first run, but removal of that provides the same error.
mentions = GET(final_url, sig)
mentions
Response [https://api.twitter.com/1.1/search/tweets.json?q=#lolhauntzer&until=2016-01-20&since_id=0&result_type=recent&lang=en&count=100]
Date: 2016-01-19 05:09
Status: 401
Content-Type: application/json; charset=utf-8
Size: 64 B
Woops. Brain lapse. Need to replace the "#" in the URL with "%40". The "#" works on my other workstation though, which is kind of baffling right now.
According to the docs you can set the date format in nginx with the command config timefmt but I can't find any documentation/example on where or how to set that.
The default shows a string like "Sunday, 26-Oct-2014 21:05:24 Pacific Daylight Time" and I want to change it to yyyyMMdd
I'm running nginx on Windows if that makes a difference.
Thank you
You must not have read the ngx_http_ssi_module documentation properly (especially its 'SSI Commands' section): it explains the commands format.
You need to set the ssi directive to on in the context you wish SSI commands to be parsed, then you need to serve files there which contains those commands.
For example:
server {
listen 8000;
index index.txt;
location / {
ssi on;
}
}
The $date_local variable states that it must be configured with the config command, by settings its timefmt parameter.
You just need to serve files which will send commands back, such as index.txt:
<!--# config timefmt="%A, %d-%b-%Y %H:%M:%S %Z" -->
The format being used by the timefmt parameter is the one of the strftime standard C function (as the documentation states).
I've found the good article about using of nginx custom log format for logstash. In one on topic comment there is:
Be careful: Between two (referrer, user agent) and four (request method, remote_user) can be set by the end-user and thus can cause the JSON to be invalid (i.e. set the user-agent to "}).
As long as nginx doesn't have explicit JSON support, I would recommend against manually >building JSON and stick to combined log which is well-supported by logstack.
How should I use custom log format to prevent this issue?
Create grok with content
NGUSERNAME [a-zA-Z\.\#\-\+_%]+
NGUSER %{NGUSERNAME}
NGINXACCESS %{IPORHOST:clientip} %{NGUSER:ident} %{NGUSER:auth} \[%{HTTPDATE:timestamp}\] "%{WORD:verb} %{URIPATHPARAM:request} HTTP/%{NUMBER:httpversion}" %{NUMBER:response} (?:%{NUMBER:bytes}|-) (?:"(?:%{URI:referrer}|-)"|%{QS:referrer}) %{QS:agent}
And filter
filter {
grok {
patterns_dir => ["Grok_DIR"]
match => { "message" => "%{NGINXACCESS}" }
}
}
It is not bulletproof in any version of nginx to hand craft the JSON - \xXX is not valid JSON encoding, it should be \u00XX. Any proper JSON parser will reject the JSON string if nginx escapes with \xXX.
If you do this with LogStash you will mostly be OK but expect json parse failures from time to time.
I think it's fine in recent versions of nginx:
Changes with nginx 1.1.6 17 Oct 2011
*) Change: now the 0x7F-0x1F characters are escaped as \xXX in an
access_log.
Changes with nginx 0.7.0 19 May 2008
*) Change: now the 0x00-0x1F, '"' and '\' characters are escaped as \xXX
in an access_log.
Thanks to Maxim Dounin.
Is there a command line utility where you can simply set up an HTTP request and have the trace simply output back to the console?
Also specifying the method simply would be a great feature instead of the method being a side effect.
I can get all the information I need with cURL but I can't figure out a way to just display it without dumping everything to files.
I'd like the output to show the sent headers the received headers and the body of the message.
There must be something out there but I haven't been able to google for it. Figured I should ask before going off and writing it myself.
I dislike answering my own question but c-smile's answer lead me down the right track:
Short answer shell script over cURL:
curl --dump-header - "$#"
The - [dash] meaning stdout is a convention I was unaware of but also works for wget and a number of other unix utilities. It is apparently not part of the shell but built into each utility. The wget equivalent is:
wget --save-headers -qO - "$#"
Did you try wget:
http://www.gnu.org/software/wget/manual/wget.html#Wgetrc-Commands ?
Like wget --save-headers ...
To include the HTTP headers in the output (as well as the server response), just use curl’s -i/--include option. For example:
curl -i "http://www.google.com/"
Here’s what man curl says about this setting:
-i/--include
(HTTP) Include the HTTP-header in the output. The HTTP-header
includes things like server-name, date of the document, HTTP-
version and more...
If this option is used twice, the second will again disable
header include.
Try http, e.g.
http -v example.org
Further into at https://httpie.org
It even includes a page to try online:
https://httpie.org/run
Telnet has for long been a well-known (though now forgotten, I guess) tool for looking at a web page. The general idea is to telnet to the http port, to type an http 1.1 GET command, and then to see the served page on the screen.
A good detailed explanation is http://support.microsoft.com/kb/279466
A Google search yields a whole bunch more.
Use telnet on port 80
For example:
telnet telehack.com 80
GET / HTTP/1.1
host: telehack.com
<CR>
<CR>
<CR> means Enter