Is this a change or regression in behavior from an earlier release of Satellite?

(In reply to Brad Buckingham from comment #1)
> Is this a change or regression in behavior from an earlier release of
> Satellite?

I didn’t try to register to another version of satellite

@Rigel The description says installing from the repo works fine, so my guess is that an index page is not being provided when you don't have a trailing slash at the end.  Which is expected behavior.  Without a trailing slash it doesn't look like a directory, so you don't get an index page.

If this is confirmed, please close as NOTABUG.

Thank you, Daniel, for looking into it. I'm deferring to ehalle as he opened the BZ.

Hi Daniel when I used the CDN in the same script and the script accepted the repo 
the script link ( https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html-single/framework_for_upgrades_13_to_16.1/index#validating-red-hat-openstack-platform-oldvernum-before-the-upgrade )
It's automatically from /etc/yum.repo.d/redhat.repo the URL.
And that is the ansible that runs behind.
---
- hosts: undercloud, overcloud
  vars:
    metadata:
      name: Check correctness of current repositories
      description: >
        Detect whether the repositories listed in `yum repolist`
        can be connected to and that there is at least one repo
        configured.

        Detect if there are any unwanted repositories (such as EPEL) enabled.
      groups:
        - pre-upgrade
  tasks:
  - name: List repositories
    command: 'yum repolist -v'
    args:
      warn: no
    changed_when: False
    register: repositories
  - name: Find repository URLs
    shell: 'echo "{{ repositories.stdout }}" | grep Repo-baseurl | sed  "s/Repo-baseurl.*\(http[^ ]*\).*/\1/g"'
    register: repository_urls
    changed_when: False
  - name: Check if there is at least one repository baseurl
    fail:
      msg: No repository found in yum repolist
    when: repository_urls.stdout_lines|length < 1
  - name: Call repository URLs
    uri:
      url: "{{ item }}"
    with_items: "{{ repository_urls.stdout_lines }}"
  - name: Find repository IDs
    changed_when: False
    shell: 'echo "{{ repositories.stdout }}" | grep Repo-id | sed "s/Repo-id.*://" | tr -d " "'
    register: repository_ids
  - name: Check if there are any unwanted repositories enabled
    fail:
      msg: Found unwanted repository {{ item.0 }} enabled
    when: item.0 == item.1
    with_nested:
      - [ 'epel/x86_64' ]
      - "{{ repository_ids.stdout_lines }}"

It's completely valid for a webserver to not redirect from a URL without a trailing slash to one with a trailing slash, just perhaps a little atypical.  Is adjusting the script an option?

I can file an issue to implement automatic redirection but this isn't a very common complaint for us.

Hi,
the script is built in the ansible triplo, it is possible to change that but I am not sure if it will help us.
we can do manual commands (curl) to test.

Hi, I try to do the same procedure in satellite 6.9 and it worked.

Was reverted upstream

The Pulp upstream bug status is at closed. Updating the external tracker on this bug.

All upstream Pulp bugs are at MODIFIED+. Moving this bug to POST.

Moving this out to 6.16 - we can't backport it to pulpcore 3.39, and since I don't really see any demand for it, there's no real need to work out something special.

Removing triaged keyword for reevaluation.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.