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 |