*.pkg/index.bom is not a directory

Hi,

I think this is an empirical, client-side method for determining the package type.
A folder can very well be named something like "something.pkg/", so the jamf client on the endpoint makes a request to "./index.bom" to determine the action to take (download the file "something.pkg" or browse to a folder with that name).
Before seeing this error, I didn't even think it was possible: I've always worked with flat packages (pkg and dmg).

We very recently enabled an HTTP(s)-DP (with authentication) to open our package repository to mobile workstations without requiring a specific network location (since mounting the file server obviously can't be done outside of a trusted network).

Since enabling HTTP(s)-DP, as the primary DP, I consistently see double GET requests in the Apache logs (the first with a 404 error, the second with an HTTP 200 success). Whether through automatic deployment or self-service installation(+)

For example:
http-dp.dom.tld 10.0.0.57 - XXXXX [09/Mar/2026:11:42:29 +0100] "GET /DistriPoint/Packages/PRN-Toshiba-drvs_7.x.pkg/index.bom HTTP/1.1" 404 236

http-dp.dom.tld 10.0.0.57 - XXXXX [09/Mar/2026:11:42:30 +0100] "GET /DistriPoint/Packages/PRN-Toshiba-drvs_7.x.pkg HTTP/1.1" 200 5105387

sorry, tag mistake

While browsing the community forum, I came across older, unanswered posts addressing this issue… and we don't like having 404 errors in the logs for legitimate actions without being able to fix them, isn’t it ?
I'm quite surprised (if my deduction is correct) that this somewhat dirty and noisy method hasn't been improved. There might not be a simple or less noisy solution (a single 404 hit might be preferable to more "clean" requests), but it should at least be documented.

Regards.

In your case, I think your problem stems from the fact that you're handling 404 errors in a specific way (redirecting them with a 302), which is causing the Self Service to fail.

Since the Self Service doesn't receive a 404 error (but a 302), it doesn't attempt a direct download via a second request, as in my example shown above.

Hi schiemsk,

sorry for the late reply … many thanks for your explanation
yes, you are right. My goal was to redirect every error to a webserver, that delivers garbarge data to annoy all the people that are scanning my webserver. This is a fun project what we have at work. The result is that our webserver gets scanned less often.

I had the hope that there is way to tell Self Service to download it at the first attempt

Hi David,
 

I see you're working like me, having defined an authenticated "/location/".

Therefore, the only 404 errors you might encounter within this destination will be related to Self Service.

Perhaps you could instead redirect authentication failures (a different error code) to your garbage data delivery.
 

My web repository (Apache) has:

- a default virtual host that serves no purpose whatsoever, in order to collect all requests arriving at the server's hostname or via direct IP. This is the case for most scanners.

- an other virtual host responding to an alias, handling all unexpected requests (i.e., without the specific /location/) and serving this /location/ by requiring authentication that only Jamf and its clients possess. If the authentication is successful, the only 404 errors on this /location/ cannot be considered illegitimate.

With products like an MDM (a complete and complex solution with customer support), I tend to adapt my local solutions rather than the product itself :-)

Thanks that is a good idea … I have added 401 Unauthorized to the list of error codes and also configured the webserver to redirect everything what is not /Packages/name.pkg to garbage data website

Self Service can download from the webserver and scanner get garbage data :-)

Thanks that’s been a great help :-)

I'm glad it helped :-)

In your case, I think your problem stems from the fact that you're handling 404 errors in a specific way (redirecting them with a 302), which is causing the Self Service to fail.

Since the Self Service doesn't receive a 404 error (but a 302), it doesn't attempt a direct download via a second request, as in my example shown above.