<div dir="ltr"><div><div><div>+100 to this proposal as I understand it. Having a redirect engine to serve 100% of content that is looked up via the db is a must-have for pulp3. Besides opening up object storage use cases, solving practical file system limits with symlinks, it will allow us to reorganize content on the backend without any interruption of service while serving that content. To describe that pain-point another way, moving the location of a unit *and* fixing all of the symlinks to that unit while Pulp is online is a PITA and maybe not even possible.<br><br></div><div>Also a big +1 to treating an "export to disk or a remote system for something other than Pulp to serve" as a dedicated, separate use case. I think we could get away without doing that in the MVP but maybe others think it should be in the MVP.<br></div><div><br></div>In the proposal it said that we only deliver content using XSendFile. We need a base implementation of this content serving that does not require the xSendFile. Specifically Pulp should carry a "let me serve that content for you inefficiently using Django" implementation so that developer environments can be fully functional without a webserver that has modXSendFile. The XSendFile integration should be an option feature. It should default to off, and it should be required for the MVP.<br><br></div>Also what about content protection? Are we going to use redirects with time-bombed urls? Or are we expecting the cert verification to occur twice (once for the initial request, and again to follow the 301 redirect)?<br><br>I also want to make a similar point here about carrying a content protection feature in Pulp and not relying on Apache exclusively for it. As a developer I should be able to have the same content protection features with runserver as you do with Apache so that developer environment are fully functional with runserver.<br><br></div>-Brian<br><div><br><br><br><div><div><div><br><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 12:05 PM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another aspect I'm considering is pulp serving a single publication with multiple and/or limited protocols<br>
(schemes).  This pertains to supporting both HTTP and HTTPS or limiting to only HTTPS.  As proposed, I think<br>
we get both HTTP and HTTPS for free but don't yet have a way for the content app to only support HTTPS.<br>
<br>
Would adding something like:<br>
  (bool) http_enabled<br>
  (bool) https_enabled<br>
<br>
to the Publisher and Publication make sense?<br>
<br>
Like auth, the settings could be set on the Publication by the plugin API when it get's created.  The content<br>
app could check this and 404 as appropriate.<br>
<br>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>