Project

Profile

Help

Story #1180

Updated by bmbouter over 8 years ago

A new section should be added to server.conf called [lazy] which will have a single setting named "redirect_url". This setting will be blank by default. An appropriate doc block needs to be created similar to other server.conf sections and a default value of '' needs to be added to "config.py":https://github.com/pulp/pulp/blob/6b0edf61b6b4d18bd37cbcef694b62464d9bdb44/server/pulp/server/config.py#L9. 

 A new redirect handler will need to be added at the platform level in "urls.py":https://github.com/pulp/pulp/blob/master/server/pulp/server/webservices/urls.py. I'll suggest 'v2/content/redirect'. The WSGI handler is rooted at '/pulp/api' so the user-facing full path of this redirection handler will be '/pulp/api/v2/content/redirect'. If "redirect_url" setting defined above is set, the Django handler will use the value of "redirect_url" and append the original request path and return the result as a HTTP 302 redirect. This handler should not force a specific protocol handler to use (ie: http vs https), but should simply append the string values together. If "redirect_url" is not configured (the default) this URL handler should always return a 404. If the user requested the redirect URL directly then the expected WSGI environment variables containing the "original" request won't be set so the correct response would be a HTTP 400 (Bad Request). 

 BEWARE: the "redirect_url" should probably NOT contain a protocol handler when the user specifies this setting. The redirect response will also not respond with a protocol handler. Hopefully all clients will try the redirected URL with the "same" protocol as the original request. The client is expected to preserve the protocol type (http, https, etc) when it makes the next request. The docs in server.conf should also no advocate that a protocol handler will be used. A user could specify a protocol handler, but then all responses will be forced onto the new protocol type which will break things like content protection and/or clients that don't support the specified protocol handler. 

 Client traffic is expected to arrive at this URL by each plugin having its content-serving virtualhost configured with the ErrorDocument directive. Unfortunately this needs to be added to each content type file which configures how content is served. This story has many child tasks which introduce this change in each plugin type Pulp manages. The purpose and requirements of the ErrorDocument also need to be documented in the Pulp platform docs so third party plugins can know how to participate in the lazy feature. The ErrorDocument directive is available in "Apache 2.2":http://httpd.apache.org/docs/2.2/custom-error.html and "Apache 2.4":http://httpd.apache.org/docs/2.4/custom-error.html. 

 <pre> 
 ErrorDocument 404 /pulp/api/v2/content/redirect 
 </pre> 

 The original request path will be known by request environment variables created by using ErrorDocument. The redirect handler will use the catalog data to lookup the actual unit that is being requested. If a redirect is returned, a task defined in task #1181 needs to be dispatched for the necessary unit so Pulp can download and save a copy of the unit. This dispatch will need to use apply_async_with_reservation and lock on the "unit id and path" which together guarantee uniqueness in the catalog. See task #1181 for more details on how/why. 

 A release note needs to be made indicating the existence of the new setting in server.conf.

Back