Opened 4 months ago

Last modified 5 weeks ago

#432 accepted defect

CL:OPEN on URL-PATHNAME does not redirect across different schemes

Reported by: aruttenberg Owned by: mevenson
Priority: blocker Milestone: 1.5.0
Component: streams Version: 1.5.0-dev
Keywords: has-test uri Cc:
Parent Tickets:

Description (last modified by mevenson) does not follow redirects across different schemes.


Original statement of problem:

So if you want to do something like use uiop/stream:copy-file which does something like open the source, open the dest, read/write, it will not do what you might expect. I don't see a way of controlling this behavior. Arguably the default ought to be to follow redirects and open the redirected-to file.

Subtickets (add)

Change History (8)

comment:1 Changed 4 months ago by mevenson

  • Keywords needs-test added
  • Milestone set to 1.4.1
  • Owner set to aruttenberg
  • Status changed from new to assigned
  • Version set to 1.5.0-dev

Have you tried appling CL:TRUENAME to a EXT:URL-PATHNAME? That should explicitly compute a new retrieval (or at least a cache validation) of the representation.

Bug me again if that doesn't work…

comment:2 Changed 4 months ago by aruttenberg

   (truename (pathname "")) 

yields, in "~/Desktop/test.owl"

<title>302 Found</title>
<p>The document has moved <a href="">here</a>.</p>
<address>Apache/2.4.7 (Ubuntu) Server at Port 80</address>

comment:3 Changed 4 months ago by mevenson

  • Keywords has-test uri added; needs-test removed
  • Owner changed from aruttenberg to mevenson
  • Priority changed from major to blocker
  • Status changed from assigned to accepted

comment:4 Changed 4 months ago by mevenson

Something has gone wonky with the URL-PATHNAME constructor on 1.5.0-dev, a result of the partial merge of the @Alan.Ruttenberg holiday deluge I am working from under.

Stay tuned, Bear fans.

comment:5 Changed 4 months ago by aruttenberg

Sure, blame it on me!

comment:6 Changed 7 weeks ago by mevenson

  • Milestone changed from 1.4.1 to 1.5.0

Ticket retargeted after milestone closed

comment:7 Changed 5 weeks ago by mevenson

The URL-PATHNAME constructor is working again, which reveals a more basic problem in that does not "follow" redirects across scheme change, i.e. via scheme http redirects to using scheme https.

Writing code to follow scheme changes across redirects is fairly trivial (see <>) but there are security implications here in automatically following a redirect from a secure session to an insecure one in that request headers (which may contain sensitive information used for authentication/authorization) that one intends to keep secret may be revealed.

My preference here would be to allow ABCL to follow redirects from http to https but not vice-versa, but this may be confusing to the user.

What would be an appropriate way to inform the end-user of what redirects are being followed?

Should we set up configuration options on what sort of redirects we allow, i.e

REDIRECT_ALL Follow all redirections
REDIRECT_SECURELY Never follow a redirection from a secure connection to an insecure one

I need to consider what the right behavior should be here?

comment:8 Changed 5 weeks ago by mevenson

  • Description modified (diff)
  • Summary changed from open http:// pathname doesn't follow redirects to CL:OPEN on URL-PATHNAME does not redirect across different schemes
Note: See TracTickets for help on using tickets.