| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
I think this happened when we merged the Opscode and Chef copyrights
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Depending on how you configure your Chef client, it's possible that a
later retry would have an authentication timestamp header
(`X-OPS-TIMESTAMP`) that was more than 900 seconds old. Since the Chef
server treats timestamps older than this threshold as unauthorized
requests, you would potentially get seemingly spurious "401
Unauthorized" responses from the server.
A solution is to generate the headers on each retry so that we have a
new authentication timestamp for each retried request.
Signed-off-by: Shane da Silva <shane@dasilva.io>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
|
| |
this is mildly awful, but works around the String-vs-URI crap
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
turn on only for the cookbook synchronizer
|
| |
|
| |
|
| |
|
|\
| |
| | |
Remote file download progress
|
| |
| |
| |
| | |
Add tests around progress output and tidy up
|
| |\
| | |
| | |
| | | |
https://github.com/brandocorp/chef into tm/remote_file_download_progress
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
this is part of our informal style guide, lets make it formal since
clearly its not getting followed very well.
|
| | |
| | |
| | |
| | | |
added some FIXMEs because trying to sort out types for random undocumented code was making me completely aggro
|
|/ / |
|
| |
| |
| |
| |
| |
| | |
This fixes [#2171](https://github.com/opscode/chef/issues/2171) when a
tempfile cannot be created or proper filesystem permissions do not
exist. This allows the proper exception to be thrown.
|
| |
| |
| |
| |
| | |
this is from the same ruleset that we had, but the new code catches more
conditions.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4174 Style/SpaceInsideHashLiteralBraces
1860 Style/SpaceAroundOperators
1336 Style/SpaceInsideBlockBraces
1292 Style/AlignHash
997 Style/SpaceAfterComma
860 Style/SpaceAroundEqualsInParameterDefault
310 Style/EmptyLines
294 Style/IndentationConsistency
267 Style/TrailingWhitespace
238 Style/ExtraSpacing
212 Style/SpaceBeforeBlockBraces
166 Style/MultilineOperationIndentation
144 Style/TrailingBlankLines
120 Style/EmptyLineBetweenDefs
101 Style/IndentationWidth
82 Style/SpaceAroundBlockParameters
40 Style/EmptyLinesAroundMethodBody
29 Style/EmptyLinesAroundAccessModifier
1 Style/RescueEnsureAlignment
|
| |
| |
| | |
Generated via git ls-files | xargs perl -pi -e "s/(Author.*?<[^@]+@)(?:opscode\\.com|getchef\\.com)(>)/\\1chef.io\\2/gi"
|
| |
| |
| | |
Generated via git ls-files | xargs perl -pi -e "s/[Cc]opyright (?:\([Cc]\) )?((?\!$(date +%Y))\\d{4})(-\\d{4})?([, ][ \d]+)*(,|(?= ))/Copyright \\1-$(date +%Y),/g"
|
| |
| |
| |
| |
| |
| |
| | |
This is an entirely mechanically generated (chefstyle -a) change, to go
along with chef/chefstyle#5 . We should pick something and use it
consistently, and my opinion is that double quotes are the appropriate
thing.
|
| |
| |
| |
| | |
useless use of `"#{foo.to_s}"`
|
| |
| |
| |
| | |
and use it in registration client specs
|
|\ \
| | |
| | | |
lazy the socketless require in Chef::HTTP
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
if this is always required then everything that uses Chef::HTTP will
load up chef-zero which will load up Webrick, which does DNS lookups
of the current host which causes a DNS lookup and possible timeout.
it also likely isn't doing pretty things to chef-client memory usage
and load times there as well.
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
|/
|
|
|
|
| |
Was hoping to avoid this, but there are multiple subclasses of
Chef::HTTP that interact with the server, which all must support
socketless mode.
|
|
|
|
|
|
|
|
|
|
| |
manner.
This is as per http://en.wikipedia.org/wiki/URI_scheme, and solves some
edges i.e., following (30x) URL from the "Location" header where we
have to deal with "HTTP://".
Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
|
| |
|
|\
| |
| | |
Fix a bug when receiving a relative redirect location
|
| |
| |
| |
| | |
@danielsdeleo
|
| |
| |
| |
| |
| |
| | |
Currently when you use a provider that somewhere along the line uses
Chef::HTTP.request or Chef::HTTP.streaming_request, you will receive an
error when the response is a redirect with a relative location.
|
| |
| |
| |
| | |
the log.
|
| | |
|