On Mon, Mar 15, 2004 at 03:08:48PM -0700, Michael Stenner wrote: > The issue is not that publicfile is violating the rfc. As far as I > can tell, it isn't. It is, however, behaving in a way that's > different from most other servers. We were using that common (but > not rfc-mandated) behavior to deal with a complex issue. (Please keep in mind, I have respectful intentions, and I understand that you are working hard on resolving the content-length issue) Just for clarification, it seems the rfc, in fact, _forbids_ the http/1.1 server to send content-length if transfer-encoding is sent. And it also says that if a client sees both transfer-encoding and content-length, it must ignore content-length. > using google with site:lists.dulug.duke.edu does a pretty decent job. > > yum content-length site:lists.dulug.duke.edu > > that will get you started. Well, I was hoping for some explanation what problem the content-length check is supposed to solve, but I have not been able to find the thread. Is it that you are trying to do something independently from the protocol? For example, I just commented out the three lines in urlgrabber.py, and I can now update my system (and do many other things) with yum. Can you show me an example when this change in yum will bite me? > Also check out the thread entitled YUM+FTP Funny thread, but does not explain the complex isssue you mention above. Hope you are not "seriously" subscribing to the idea that the norm is the set of features the most popular servers are providing. wu-ftpd, proftpd, BIND or sendmail may not bring fond memories to all sysadms. Mate -- --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
