Tcl Source Code

View Ticket
Login
Ticket UUID: c11a51c482ba5720793d44340f76934c59718780
Title: Configuration race condition in accept types
Type: Bug Version: http 2.8.8
Submitter: dkf Created on: 2014-07-06 17:13:33
Subsystem: 29. http Package Assigned To: nobody
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2015-05-18 07:53:54
Resolution: Fixed Closed By: dkf
    Closed on: 2015-05-18 07:53:54
Description:

If you're using the http package to do REST with content type negotiation, you need to configure the package's Accept: types mechanism from time to time. This is a bit of a broken API, in that there's no option to override from options passed to http::geturl. This is not the feature change I'm requesting.

However, if you're also using asynchronous connecting then you've got an additional problem in that the configuration of the -accept option is only read when the connection is made; two connections that require different Accept: headers will have a race condition between the two, and so which is used will be pretty much random. This Is Wrong. This is the bug I'm reporting.

Suggested fix, without fixing the original API botch, is to take a copy of $http(-accept) into the state array during http::geturl so that the value used in http::Connected is predictable.

See also: this thread with the comment that prompted me to look into the potential feature request, and discover the race:

Ok well the final solution was that using -headers in the http::geturl doesn't seem to work when setting an "Accept" header - which kind of sucks…

User Comments: dkf added on 2015-05-18 07:53:54:

Both kinds of fixes applied. The value of the -accept option is now saved during http::geturl, and the existing -headers can now override it.