On 2013/06/17 13:12, Stuart Henderson wrote: > On 2013/06/17 12:57, Stuart Henderson wrote: > > On 2013/06/17 12:40, David Coppa wrote: > > > pcsc-lite's master site changed something and now I cannot download > > > their distfiles using ftp(1): > > > > > > $ ftp -v -o ccid-1.4.11.tar.bz2 > > > "https://alioth.debian.org/frs/download.php/file/3920/ccid-1.4.11.tar.bz2"; > > > Trying 217.196.43.134... > > > Requesting > > > https://alioth.debian.org/frs/download.php/file/3920/ccid-1.4.11.tar.bz2 > > > ftp: Error retrieving file: 406 Not Acceptable > > > > > > Something fishy wrt https? > > > > > > wget wants "--no-check-certificate" to successfully retrieve this file... > > > > > > cheers, > > > David > > > > > > > It's not to do with the certificate; ftp(1) does absolutely no cert > > checking. > > > > (also, this file is available by http as well, which fails in the same way). > > > > Strangely, > https://alioth.debian.org/frs/download.php/latestfile/112/ccid-1.4.11.tar.bz2 > works >
For the original URL it wants an "Accept: */*" header. RFC2616 (HTTP/1.1) says, "If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response." so based on this, I'd say it's a bug in fusionforge. There's some old W3C document which says "If no Accept: field is present, then it is assumed that text/plain and text/html are accepted" but this isn't in either HTTP/1.0 or HTTP/1.1 RFCs.
