Many debug logs have no line breaks, so fix them here.
- With pull requests:
- Open your pull request against `master`
- Your pull request should have no more than two commits, if not you should squash them.
- It should pass all tests in the available continuous integrations systems such as TravisCI.
- You should add/modify tests to cover your proposed code changes.
- If your pull request contains a new feature, please document it on the README.
The `<link>` element is an empty element, it contains attributes only. In HTML5 the `<link>` tag has no end tag. In XHTML the `<link>` tag must be properly closed.
When `gin.Context.FormFile("...")` is called the `engine.MaxMultipartMemory` is never used. This PR makes sure that the `MaxMultipartMemory` is passed and removes 2 calls to `http.Request.ParseForm` since they are called from `http.Request.ParseMultipartForm`
Digging into the test code base I've found out that some of the tests for `LoadHTML*` methods are not reliable and efficient. They use timeouts to be sure that goroutine with the server has started. And even more, in old implementation, the server started only once – all the new instances silently failed due to the occupied network port.
Here is a short overview of the proposed changes:
- it's not necessary to rely on timeouts, the server starts listening synchronously and returns control when it is ready
- once the server is run, it's stopped after a test passes
- dry out http server setup
- magic with empty closure return is eliminated
- preserve router.RunTLS coverage with integration tests
As per #1230 there is an issue when using HandleContext where the context of the request is returned to the context sync.Pool before the parent request has finished, causing context to be used in a non-thread safe manner.
I've removed the bug by not entering the context back in the pool and leaving that to ServeHTTP.
There was no test coverage for this function so I've also added the test to cover it. As the bug only happens when there are concurrent requests, the tests issues hundreds of concurrent requests. Without the bug fixed the tests do consistently recreate the error.
1. Why is this change neccesary?
White text on a yellow background was illegible with most terminal color schemes
2. How does it address the issue?
The white text was replaced with a bash compatible dark gray while keeping the
yellow background colour
3. What side effects does this change have?
Resolves#1552