handler: Allow media type parameters in Content-Type headers

[masewo]

This pull request includes several changes to the pkg/handler package, focusing on improving the handling of MIME types and adding new tests. The most important changes include fixing a regular expression, updating comments, modifying the MIME type whitelist, and adding new unit tests.

Improvements to MIME type handling:

• pkg/handler/unrouted_handler.go: Fixed a regular expression in reMimeType to correctly match MIME types with a plus sign.
• pkg/handler/unrouted_handler.go: Updated comments to correct typos and improve clarity.
• pkg/handler/unrouted_handler.go: Added video/mp4 to the mimeInlineBrowserWhitelist and reordered entries for better readability.

Testing enhancements:

• pkg/handler/unrouted_handler_test.go: Changed the package name from handler_test to handler to allow testing of unexported functions.
• pkg/handler/unrouted_handler_test.go: Added a new test function TestFilterContentType to ensure the filterContentType function behaves correctly with various metadata inputs.

[Acconut]

Great to hear that we are now on the same page!

[Acconut]

Can you please have a look at the failing tests?

[masewo]

non-a-valid-mime-type is now a valid mime type. I changed it to non a valid mime type.

[masewo]

@Acconut Seems like a flaky e2e test. The TestUnexpectedNetworkReset sometimes fails on Windows, because the PATCH and HEAD requests happen too fast after each other, causing the file locker not unlock the lock file fast enough. Happens for me in every 10th run or so.

Adding a bit of delay between PATCH and HEAD seems to let pass the test more reliable, but maybe it also hides some underlying problem.

A conn.(*net.TCPConn).CloseWrite() (flush the sent data) before the RST seems to work also. According to Wireshark the RST gets send anyway. But maybe it is changing the purpose of this test too much.

[Acconut]

Thank you for your contribution!

[Acconut]

@Acconut Seems like a flaky e2e test. The TestUnexpectedNetworkReset sometimes fails on Windows, because the PATCH and HEAD requests happen too fast after each other, causing the file locker not unlock the lock file fast enough. Happens for me in every 10th run or so.

Thank you for looking into the failing e2e although it's not caused by your PR here. I have also noticed that it randomly fails on Windows, while working fine on Linux. It seems to be caused by minor differences in Go's or the OS' networking stack on these platforms.

Adding a short delay between the PATCH and HEAD request is fine. The test is about ensuring that tusd saves data even when the TCP connection is reset. This goal will not be compromised by a short delay.

That being said, it seems like tusd on Windows is returning internal server errors where it actually should return ErrFileLocked:

level=ERROR event=InternalServerError method=HEAD path=b31ad07cb800343739b5b9ad38a0e720 requestId="" id=b31ad07cb800343739b5b9ad38a0e720 message="open D:\a\tusd\tusd\internal\e2e\data\b31ad07cb800343739b5b9ad38a0e720.lock: Access is denied."

and

event=InternalServerError method=HEAD path=b2fd0bd224ede04083b048e03372db84 requestId="" id=b2fd0bd224ede04083b048e03372db84 message="open D:\a\tusd\tusd\internal\e2e\data\b2fd0bd224ede04083b048e03372db84.lock: The process cannot access the file because it is being used by another process."

Feel free to open another PR for the delay, if you are interested