Detect directory paths in object get without recursive flag

[Copilot]

• Remove redundant recursiveFromQuery check
• Add specific ParameterError type validation in test
• Restore recursiveFromQuery logic with simplified condition
• Verify compilation
• Run tests
• Final code review

Changes Made

Issue 1: Simplified recursiveFromQuery check (handle_http.go:1242)

The original suggestion was to remove the redundant tj.rejectCollections check in the condition, not to remove the entire block. The corrected logic:

if recursiveFromQuery {
    tj.rejectCollections = false
}

This ensures that when a URL query parameter forces recursive mode, we unconditionally clear rejectCollections.

Issue 2: More specific error validation (fed_long_test.go:1042)

Added proper error type checking:

var pe *error_codes.PelicanError
require.True(t, errors.As(getErr, &pe), "Error should be wrapped in PelicanError")
assert.Equal(t, 1000, pe.Code(), "Should be Parameter error code")

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Ungraceful Handling of Object Retrieval with Directory Path</issue_title>
<issue_description>When a directory path is passed to the pelican object get command without the recursive flag, it is not handled gracefully. Here is the current behavior:

• Standard flow through Cache:
  An error is printed, and an empty file is created at the destination.

• Direct read through Origin:
  The command runs successfully. A file is created at the destination, containing HTML of a table listing the contents of the requested directory.

</issue_description>

Comments on the Issue (you are @copilot in this section)

@brianaydemir I was able to reproduce this just now, including when going through a cache (which was not the case when this issue was originally written). @brianaydemir Testing with a v7.22.0 client against a v7.23.0-rc.2 origin and cache, a `pelican object get` on a path that maps to a directory on a POSIX file system results in an HTML file produced by XRootD that contains a listing of the directory's contents. This happens when going through the cache and when reading directly from the origin. @brianaydemir Closing as not planned. I don't want to change how we configure XRootD by default, e.g., by turning off its directory listings, and in the absence of reports from users, it's not clear it's worth the effort to update the client and caches to check for `get`s on directories. @bbockelm Eh -- this is simpler than you might think, especially after some work done last fall to make sure PROPFIND functions.

In all cases for downloading an object in non-recursive mode, it appears we do at least one HEAD (to see if the cache is alive or to get the final size of the object if we didn't try to sort cache attempts). If the HEAD comes back with a non-zero Age, then it must be an object.

If we get to this statanza:

Worst case: do a separate HEAD request to get the size

we now need to determine if it's a collection as well as a guess for size -- we can definitely do a PROPFIND instead.</comment_new>

• Fixes Ungraceful Handling of Object Retrieval with Directory Path #1706

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

All items addressed.

[turetske]

@copilot The check of tj.rejectCollections is redundant, no matter what it is it will end up as false.

[Copilot]

Fixed in commit 0b70906. Removed the redundant check - when recursiveFromQuery is true, recursive is already true, so rejectCollections would never have been set to true in the first place.

[turetske]

@copilot I believe we can be more specific? Isn't this a pelican parameter error?

[Copilot]

Fixed in commit 0b70906. Now validates that the error is specifically a ParameterError with code 1000:

var pe *error_codes.PelicanError
require.True(t, errors.As(getErr, &pe), "Error should be wrapped in PelicanError")
assert.Equal(t, 1000, pe.Code(), "Should be Parameter error code")

[turetske]

@copilot Is this correct? I suggested just removing the tj.rejectCollection but keeping recursiveFromQuery. Basically, if recursiveFromQuery, then tj.rejectCollections = false.

[Copilot]

You're right, I misunderstood. Fixed in commit 23647a9. Now keeping the logic but with the simplified condition:

if recursiveFromQuery {
    tj.rejectCollections = false
}

This removes the redundant tj.rejectCollections check while preserving the behavior of clearing rejectCollections when the URL query forces recursive mode.

[turetske]

@bbockelm Passing this back to you