I had a very similar issue that JAMF helped me to resolve. In my case, Server.app on 10.10 server had done two things that were getting in the way:
1) there was a redirect set in the Websites section of Server Admin that forwarded all https traffic to http. I didn't set this redirect; it must have been done during Server Admin's setup.
2) Also in the Website section, we had to set the "Store Site Files" to be the Shared Items folder, not the "CasperShare" or "Packages" folder. Seems the http query couldn't navigate the path correctly otherwise. Also something I didn't explicitly setup.
To simplify, I just encountered this with 9.81 and it's only on a couple clients with interrupted downloads. Clearing client cache of the partial download at /Library/Application Support/JAMF/Downloads in my case resolves the problem, circumventing the HTTP resume call.
Thu Feb 11 11:03:01 XX-DC063 jamf[61893]: Executing Policy X...
Thu Feb 11 11:03:03 XX-DC063 jamf[61893]: The network connection was interrupted while downloading the package from http://xx-jssrepo.xxx.com:8080/Packages/X.pkg. Attempting to reconnect...
Thu Feb 11 11:03:03 XX-DC063 jamf[61893]: The network connection was interrupted while downloading the package from http://xx-jssrepo.xxx.com:8080/Packages/X.pkg. Attempting to reconnect...
Thu Feb 11 11:03:03 XX-DC063 jamf[61893]: Error: X.pkg is not available on the HTTP server.
access_log (server is two minutes off):
[11/Feb/2016:11:05:23 -0500] "GET /Packages/X.pkg HTTP/1.1" 416 386 "-" "jamf (unknown version) CFNetwork/760.2.6 Darwin/15.3.0 (x86_64)"
After clearing the partial X.pkg in /Library/Application Support/JAMF/Downloads
Thu Feb 11 11:06:03 XX-DC063 jamf[63698]: Checking for policies triggered by "X"...
Thu Feb 11 11:06:06 XX-DC063 jamf[63698]: Executing Policy X...
Thu Feb 11 11:06:11 XX-DC063 jamf[63698]: Verifying package integrity...
Thu Feb 11 11:06:11 XX-DC063 jamf[63698]: Installing X.pkg...
Thu Feb 11 11:06:20 XX-DC063 jamf[63698]: Successfully installed X.pkg.
Additionally I tried re-creating the issue by interrupting curl with ^C downloading X.pkg to simulate a resume request. The result was that casper behaved perfectly. Thinking it through... I checked the file sizes.
Cached failed download had a file size of: 46170984
The file size of the current package on the repo: 46163264
The file on the repository is smaller than the one attempting to be resumed. Therefore the start offset for resume was beyond the EOF of the file in the repository - thus the error.
Looking up HTTP response 416
416 Requested Range Not Satisfiable
Makes sense.
I suspect either the interrupted transfer got garbage tacked onto it, or the interruption corrupted the allocation of the file thus it was oversized. Or we've since replaced the package with one slightly smaller.
The long and short of it is (unexpected pun alert!) is that we should be able to get JAMF to resolve this defect by implementing either a file size check or wiping the cached file on HTTP resume failure or even more correctly when it senses a 416 HTTP response code.
@NightFlight This is a known issue and you should sign up for 9.9 Beta 1. Check for defect: [D-009836] HTTP Downloads will not resume or overwrite if a package is detected in the /L/AS/JAMF/Downloads folder
I can also confirm this is a defect - [D-009836]. We have this issue on around 40 of our JSS's. Bit of an issue as it's making our MySQL swell with all of the failed policies.
@bpavlov JAMF has a public/customer facing bug tracker? A serach for [D-009836] brings up nothing for me.
@NightFlight Jamf's bug tracker is secret. Your TAM may clue you in if you run into a bug. If you find a bug, they'll give you the number so you can watch for it in release notes of new versions.
I've also seen plenty of download errors (http) in the logs, but after trying again they run successfully. And like others, trying to download manually using the URL and everything works so I know my server is just fine.
@NightFlight They do not as already mentioned. It just so happens to be the second most requested feature:
https://jamfnation.jamfsoftware.com/featureRequest.html?id=1699
One of the benefits to Encompass is getting detailed support history for your account, but probably won't get you defects info not related to your account.
I agree, having an open defects database, at least open to Encompass customers, would be extremely helpful.
Don
@donmontalvo What is Encompass? And why would a JAMF defects db be available only to Encompass customers? It should be available to all JAMF customers.
@bpavlov information about Encompass can be found here. I agree, a public facing defects database should be available to all customers.
At minimum clients that are current on licensing should have access to a defect list. Hiding it or making paying clients pay a "premium" to see a monthly defects report is bad business.
Well, everyone pretty much agrees that the Apple model sux in this respect. Should we just start a public/external 'Radar' for JAMF ;-)
I've suggested that on Slack. Not sure what we would use to track the bugs though. Github? Between release notes which have some defects listed, and what customers have it would provide at least a place where people can search which is better than nothing at this point.
It would just be a wish on my part. I don't have the bandwidth to start/maintain it - our IT department runs pretty lean...
Is this really still an open defect? I have encountered this periodically since we first started using JAMF (9.32) up until now (9.97) and we are still getting this when pushing large packages, such as creative cloud.
Executing Policy ac-PushAdobeCreativeCloud
Resuming download of http://10.12.1.51/Packages/ev-creative-cloud-all-no-scout-no-acrobat-17.3.17-install.pkg.zip...
Error: Could not connect to the HTTP server to download ev-creative-cloud-all-no-scout-no-acrobat-17.3.17-install.pkg.zip.
@lynnp that doesn't look like the D-009836 issue resolved in 9.9, at a glance.
That looks more like network anomalies causing download to stop/start (resume).
we are still getting this when pushing large packages, such as creative cloud.
We cache all PKGs over a certain size...um...Creative Cloud packages would surely exceed our threshold. :)
@donmontalvo Oh. I suppose if I were actually able to read the defect report that might have been useful 
I really dislike that I have to use my JAMF Buddy as an interface for that information.
What sort of "network anomalies" would consistently affect only JAMF's process for this? This is all internal over a gigabit network. Certainly curl is robust enough to not freak out about even a 20GB download..
Is there a way of configuring the jamf binary to be more tolerant of whatever it is that's causing it to bail out? Or possibly adjusting apache config on the distribution share side?
Caching locally doesn't help us for pushing out the initial install via policy.
FYI, we wrote a script that curls the package from the same fileserver, unzips, and runs installer and it works 100% of the time. It's hard to think that this isn't the jamf binary doing something stupid that it thinks is really clever.
I'm still seeing the file not found error for the index.bom on HTTP delivery of a .pkg file on JAMF Pro 10.5. :(
Probably a silly question, but does this phantom index.bom file come from indexing a .pkg file (as opposed to a .dmg)?
