Browse Prior Art Database

Web servers with advanced logging mechanism to provide detailed request details upon specific response codes

IP.com Disclosure Number: IPCOM000247929D
Publication Date: 2016-Oct-11
Document File: 1 page(s) / 105K

Publishing Venue

The IP.com Prior Art Database

Abstract

In SaaS world, especially a multi-tenant web application at times, web servers (single or pooled) get all the requests from various users of various clients. They respond with dynamic responses to the browsers along with the response codes, in case of some server errors, they respond with HTTP status codes of 500+. Upon enabling logging at the web server levels, only some basic information can be captured like the requested URL (with query string), timestamps, remote ports, response codes etc. For diagnosis purpose (in such scenarios) we have to buy & install other 3rd party software, so that we capture more details of the request and replay it. Instead if servers come with advanced logging mechanism (only in such error scenarios) and provide a subscription based option to react in real-time, that'll make the diagnosis very efficient and timely.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 76% of the total text.

Page 01 of 1

Web servers with advanced logging mechanism to provide detailed request details upon specific response codes

This proposal is about having a sub‐module in a web server, that captures and stores the entire  request content (URL, headers, cookies, form body etc..) upon encountering a server error while  serving the particular request. This should be configurable to decide what details to be captured and  specific response codes which will act as the triggers. This information will be stored in the web  server's data store, or additional data stores can be configured to be stored by the web server. This data can be viewed and queried later or a subscription model should be provided where the data  can be queried in real‐time and stored/handled by the subscribing web applications. This request content is good enough to recreate/replay those transactions can be replayed with  appropriate session related modifications (for developers to diagnose the issue). Web server doesn't  need to log all this data for each transaction, only in case of server errors, this will happen.

 

Benefits:

No additional appliance/software will be needed to achieve this

    Specific programming logic needn't be there in the web applications By default, easily maintained by web servers
Can be queries & replayed any...