I went to my App services > my app > Monitoring > Diagnostic logs
And there I enabled both: Application Logging (Blob) and Web server logging (Storage)
The above settings started logging a .log file in which every row is an HTTP request to my app, with these headers:
#Fields: date time s-sitename cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken
I'm interested in logging the POSTed JSON for the requests that the server is responding HTTP 500. How can I achieve this from the Azure portal?
How can I achieve this from the Azure portal?
Azure Web App doesn't provide this feature default. I suggest you add a event handler for application level exception. In this handler, you could log the request body or the information of exception. Code below is for your reference.
protected void Application_Error(object sender, EventArgs e)
{
string req_JSON;
using (StreamReader reader = new StreamReader(Request.InputStream))
{
req_JSON = reader.ReadToEnd();
}
//you could log the json to anywhere you want
Exception excpt = Server.GetLastError().GetBaseException();
//you also could log the exception which encounted at server
}
Not clear what you are using to write your app, but if you are using .net you would need to use the System.Diagnostics.Trace namespace.
in this case since you are getting a 5XX http error, I asume there is some sort of exception being thrown that is missing a try/catch.
Once you find that, then you add something like:
System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened " + postedJSON);
This will result in the json being added to the application log.
You can get more info about App Service logging here: https://learn.microsoft.com/en-us/azure/app-service/web-sites-enable-diagnostic-log
I have a C# based webAPI hosted on Azure WebApp.
Sporadically, the HTTP OPTIONS call fails with a 500 error.
The OPTIONS call is not handled by our code. So I assume the server handles it by itself.
I tried enabling logs but both event log and web server logs does not print anything other than that it failed with a 500 error.
Any ideas why this would happen?.
Update:
I see only the below error messages in the web server logs. No details
Additionally I added code in my webAPI to handle options call, but the code does not go there. Not sure if I need to enable/disable something in web.confi.
2017-08-31 11:49:39 xxx.mywebsite.com OPTIONS /api/apiname StartDate=2017-08-25&EndDate=2017-08-31&X-ARR-LOG-ID=d86ffe7f-32c9-410b-8116-65833d5af7b9 443 - xxx.xxx.xxx.xxx Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/60.0.3112.113+Safari/537.36 - www.website.com 500 121 0 636 1612 230013
I wrote a simple RESTful web service API using WCF 4.5 to exchange data with our iPhone application. The service is hosted at my office on a Windows 2012 Server with IIS 8.0 and is exposed externally through my company's domain (i.e. https://api.company.com/).
The issue that I am having is that when I access my API from a WiFi network on my phone I am seeing relatively fast response times (~1s) but when I access my API from my AT&T LTE connection the response times are brutally slow most of the time (~10-20s). According to http://www.speedtest.net, my download and upload speeds on LTE are actually faster than my WiFi connections.
I have performed my tests both in the office and away from the office. While at the office the WiFi network is on the same internal network as the server, but while at my home my WiFi network is not on the same network. I see the same ~1-2s response times on WiFi whether at home or in the office and I see the same ~10-20s response times on LTE in both locations.
I have enabled some logging on IIS to see reveal the individual requests with their response times. I changed my search query each time to ensure that the response wasn't being cached somewhere. I am only pulling back the first 100 records so the duration of the query should be about the same for any letter of the alphabet. The 50.x.x.x address is from my home WiFi and the 166.x.x.x address is from the LTE connection. The first request made on LTE actually timed out here and sited the sc-win32-status of 995 (ERROR_OPERATION_ABORTED). This happens from time to time and I am not sure what the issue is there either or if it is related. One of the queries on LTE (q=j) took 3s.
#Fields: date time cs-method cs-uri-stem cs-uri-query s-port c-ip sc-status sc-substatus sc-win32-status time-taken
2015-05-19 01:29:21 GET /v1/users q=a 443 50.130.105.236 200 0 0 1762
2015-05-19 01:29:25 GET /v1/users q=b 443 50.130.105.236 200 0 0 1060
2015-05-19 01:29:29 GET /v1/users q=c 443 50.130.105.236 200 0 0 1060
2015-05-19 01:29:33 GET /v1/users q=e 443 50.130.105.236 200 0 0 1294
2015-05-19 01:29:39 GET /v1/users q=e 443 50.130.105.236 200 0 0 3151
2015-05-19 01:29:44 GET /v1/users q=f 443 50.130.105.236 200 0 0 1294
2015-05-19 01:30:11 GET /v1/users q=g 443 166.170.53.188 200 0 995 20156
2015-05-19 01:30:51 GET /v1/users q=h 443 166.170.53.188 200 0 0 19438
2015-05-19 01:30:59 GET /v1/users q=j 443 166.170.53.188 200 0 0 2979
2015-05-19 01:32:43 GET /v1/users q=k 443 166.170.53.188 200 0 0 23931
2015-05-19 01:32:57 GET /v1/users q=l 443 166.170.53.188 200 0 0 8502
2015-05-19 01:33:03 GET /v1/users q=m 443 50.130.105.236 200 0 0 2308
2015-05-19 01:33:06 GET /v1/users q=n 443 50.130.105.236 200 0 0 1372
2015-05-19 01:33:11 GET /v1/users q=o 443 50.130.105.236 200 0 0 1560
2015-05-19 01:33:16 GET /v1/users q=p 443 50.130.105.236 200 0 0 1419
I have tried configuring Failed Request Tracing in IIS for when the time-taken is > 5 seconds (using this post). The longest duration in the event log was ~1s between AspNetHttpHandlerEnter and AspNetHttpHandlerLeave and I couldn't figure out why the requests were taking > 5 seconds on LTE.
Additional Info
The service is secured using HTTPS and basic authentication.
The service uses Entity Framework 6.0 and SQL Server
The payload is JSON and compressed using gzip
The amount of data being transferred is less than 10kB
The service is not currently using any async calls
The service is being accessed very lightly at the moment (<500 calls per day)
We are trying to implement client certificate authentication in IIS 7.5. We have configured many-to-one mapping, disabled all other authentication modes and now the cert-authentication seems to work correctly: we can correctly read the certificate information from a test .aspx page and also the authenticated username is the one configured in many-to-one mappings.
However, even though everything seems to work correctly, each "new" browser session causes one "extra" error status 500 row in the IIS log, just before the authentication is successful:
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port ... cs-host sc-status sc-substatus sc-win32-status time-taken
2013-02-12 09:46:35 10.40.64.45 GET /certtest.aspx - 443 - ... - site.mydomain.com 500 0 64 31
2013-02-12 09:46:35 10.40.64.45 GET /certtest.aspx - 443 - ... - site.mydomain.com 200 0 0 734
Same "extra" error status 500 issue happens for any file, e.g. for images, .css, .js, so certainly it's not a problem in the certtest.aspx file.
Any ideas, what could cause this error status 500 in IIS?
It seems that we managed to solve this issue by setting the SSLAlwaysNegoClientCert Metabase Property to True.
Technet article from IIS6.0 (!) Admin reference
I want to know if libcurl supports the multicast file transfer.
curl is a command line tool for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, Gopher, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, Telnet and TFTP. curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, kerberos...), file transfer resume, proxy tunneling and
FEATURES
curl tool
- config file support
- multiple URLs in a single command line
- range "globbing" support: [0-13], {one,two,three}
- multiple file upload on a single command line
- custom maximum transfer rate
- redirectable stderr
libcurl supports
- full URL syntax with no length limit
- custom maximum download time
- custom least download speed acceptable
- custom output result after completion
- guesses protocol from host name unless specified
- uses .netrc
- progress bar/time specs while downloading
- "standard" proxy environment variables support
- compiles on win32 (reported builds on 40+ operating systems)
- selectable network interface for outgoing traffic
- IPv6 support on unix and Windows
- persistant connections
- socks5 support
- supports user name + password in proxy environment variables
- operations through proxy "tunnel" (using CONNECT)
- supports large files (>2GB and >4GB) both upload/download
- replacable memory functions (malloc, free, realloc, etc)
- asynchronous name resolving (*6)
- both a push and a pull style interface
HTTP
- HTTP/1.1 compliant (optionally uses 1.0)
- GET
- PUT
- HEAD
- POST
- Pipelining
- multipart formpost (RFC1867-style)
- authentication: Basic, Digest, NTLM(*9), GSS-Negotiate/Negotiate(*3) and
SPNEGO (*4) to server and proxy
- resume (both GET and PUT)
- follow redirects
- maximum amount of redirects to follow
- custom HTTP request
- cookie get/send fully parsed
- reads/writes the netscape cookie file format
- custom headers (replace/remove internally generated headers)
- custom user-agent string
- custom referer string
- range
- proxy authentication
- time conditions
- via http-proxy
- retrieve file modification date
- Content-Encoding support for deflate and gzip
- "Transfer-Encoding: chunked" support for "uploads"
HTTPS (*1)
- (all the HTTP features)
- using client certificates
- verify server certificate
- via http-proxy
- select desired encryption
- force usage of a specific SSL version (SSLv2(*7), SSLv3 or TLSv1)
FTP
- download
- authentication
- kerberos4 (*5), kerberos5 (*3)
- active/passive using PORT, EPRT, PASV or EPSV
- single file size information (compare to HTTP HEAD)
- 'type=' URL support
- dir listing
- dir listing names-only
- upload
- upload append
- upload via http-proxy as HTTP PUT
- download resume
- upload resume
- custom ftp commands (before and/or after the transfer)
- simple "range" support
- via http-proxy
- all operations can be tunneled through a http-proxy
- customizable to retrieve file modification date
- no dir depth limit
FTPS (*1)
- implicit ftps:// support that use SSL on both connections
- explicit "AUTH TSL" and "AUTH SSL" usage to "upgrade" plain ftp://
connection to use SSL for both or one of the connections
SCP (*8)
- both password and public key auth
SFTP (*8)
- both password and public key auth
- with custom commands sent before/after the transfer
TFTP
- download / upload
TELNET
- connection negotiation
- custom telnet options
- stdin/stdout I/O
LDAP (*2)
- full LDAP URL support
DICT
- extended DICT URL support
FILE
- URL support
- "uploads"
- resume
FOOTNOTES
=========
*1 = requires OpenSSL, GnuTLS, NSS, yassl, axTLS or PolarSSL
*2 = requires OpenLDAP
*3 = requires a GSSAPI-compliant library, such as Heimdal or similar.
*4 = requires FBopenssl
*5 = requires a krb4 library, such as the MIT one or similar.
*6 = requires c-ares
*7 = requires OpenSSL or NSS, as GnuTLS only supports SSLv3 and TLSv1
*8 = requires libssh2
*9 = requires OpenSSL, GnuTLS, NSS or yassl