Bug 140387
| Summary: | yum header FTP download fails with: 501 REST not compatible with server configuration | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Deron Meranda <deron.meranda> |
| Component: | yum | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | katzj, rtomayko |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-06-20 19:59:56 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Deron Meranda
2004-11-22 18:53:28 UTC
We have a couple of options at the urlgrabber level which were noted in the original report: 1. Fake it. We can act like we have REST support by RETRing the file starting at byte 0 like normal, read and disgard up to the first byte of the range, read the range, and then close the connection. At first I thought this would be too time consuming but in the case of yum it may be viable if the RPM header is fairly close to the beginning of the file. 2. WONTFIX in urlgrabber. Raise this exception up to yum and let yum try to fallback on the header file. Seth, is the header usually pretty close to the beginning of the file? I had originally planned to emulate byte-ranges for servers that don't support it by reading-and-disgarding up to the range offset but I wasn't sure it would ever really be used and the logic will be a little on the complex side. I looked throught the repo xml files for all of the RPMs in FC3, and the header data for all packages always starts at byte offset 440. So, I would think that reading from byte 0 and discarding would seem to be a pretty reasonable thing to do. I don't know about all RPMs though. Perhaps you could just define some limit (10k?), beyond which you refused to do the read-and-discard routine? About ProFTPd in particular; I'm convinced not accepting REST is their problem, a misinterpretation of the FTP standards. It has a feature where uploaded files are saved with a random temporary "hidden" name until the upload completes, at which point the file is renamed to it's intended name. This is meant to prevent people seeing partial files. That feature is quite obviously incompatible with REST when used with uploading. However there is no reason not to allow REST when downloading, which is what yum uses it for. I've started raising the issue with them but don't know if it will ever be fixed. ... However, I still think that the yum urlgrabber problem should be fixed anyway. comment #1: It's close but not extremely close - it varies based on the number of signatures on the rpm. Shortest distance is 120bytes, iirc. I say fake it - if you can't open it - go from 0 until the closest byte. I think my readheaderFromFile function will handle it. If not, we'll find out. :) Comment #2: it varies based on number of sigs on the package. This is fixed in urlgrabber CVS. When urlgrabber runs into a server that returns 501 to a REST request, it will send a normal RETR, and gobble up any bytes leading up to the beginning range. I've tested against ProFTPD 1.2.10 (stable) with the HiddenStor option enabled. When this will be included in Yum is up to Seth and Jeremy. |