September 2020 Update
History Chart
We updated the history chart UI with a dropdown list to make it easier for users to select common metrics such as response time and status code. Of course, you can select the response body option in the dropdown, where a search box will appear for you to draw charts for certain properties from the response body.
This change makes it easier for new users to explore the feature and also makes the chart section more concise. And don't forget that you can add bookmarks for your charts for easy future access. For more details, please see our doc page.
Response Time Metrics:
Response Body Property Metrics:
Follow HTTP Redirect
On the task execution front, we added a setting to allow tasks to automatically follow HTTP redirect when issuing a POST request. Before this enhancement, iHook only follows redirects for non POST requests, as specified in HTTP RFC 2616. Now you can relax the restriction by enabling the task setting under the Advanced Option section.
HTTP Request Header Override
When iHook sends HTTP requests, a couple of headers such as User-Agent and Accept are added by default to maximize the chance for a request to succeed (You can inspect each request's header information under the History section).
Now you can override those pre-defined header values. For example, you can assign a browser User-Agent value such as Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11 to better simulate browser requests. The override will be case insensitive.
Auto Disabling
If a task could not receive a response from the remote side after 15 seconds, and if this happens 3 times in a row, iHook would disable the task and notify you via email. Now we are extending this behavior for tasks with 4xx and 5xx response status code.
We realize that most users would end up with a 2xx status code if their HTTP requests were to achieve something meaningful. With this change, it would allow us to better allocate our task scheduling resource and notify users when requests receive bad status code.
Surely some users would still be interested in 4xx and 5xx status code. To avoid auto disabling, you can create notification rules that check for status code. That way we would know that you are making a conscious decision about the expected HTTP response status code for a task. As long as such rules are present, no auto disabling would occur on 4xx and 5xx status code.
Thank You
Thank you for reading and thank you for your continued support for iHook! As always, if you have any feedback on our product and features, please contact us at [email protected], we look forward to hearing from you!