Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
On Sun, 22 Jun 2008 10:32:50 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Bjoern Hoehrmann wrote: * Jonas Sicking wrote: It makes no sense to me to for HTTP say that the total number of bytes should include HTTP headers. It would be similar to including the TCP headers in the IP packets IMHO. There is a big difference here, an application might not have meaningful access to the latter, but would necessarily have meaningful access to the former (even if only to the next hop). I don't see how ability to get hold of one or another makes a difference in determining whether it's the right or the wrong data. There is lots of data available that would be the wrong data, that doesn't change the fact that it's the wrong data. The consequence of not in- cluding headers would be, e.g., that on HEAD requests you would seem to never make any progress. Yes, I agree that this is somewhat unfortunate. Though in reality I doubt that it will matter much since headers are usually small enough that you don't really need progress reports on them. Well, until you get some mobile network crawling along sending an accept header ... Seriously, this is the sort of problem that makes me want to define this as application-specific. Because it makes no sense to me that a GET request counts the returned header as content, but it makes sense to me that a HEAD request does, and I am not sure what makes sense for PUT. Using it for mail, where you are transferring an entire mailbox as a single object it seems natural to count the mail headers, but shifting an individual message I am not so sure... Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
Charles McCathieNevile wrote: On Sun, 22 Jun 2008 10:32:50 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Bjoern Hoehrmann wrote: * Jonas Sicking wrote: It makes no sense to me to for HTTP say that the total number of bytes should include HTTP headers. It would be similar to including the TCP headers in the IP packets IMHO. There is a big difference here, an application might not have meaningful access to the latter, but would necessarily have meaningful access to the former (even if only to the next hop). I don't see how ability to get hold of one or another makes a difference in determining whether it's the right or the wrong data. There is lots of data available that would be the wrong data, that doesn't change the fact that it's the wrong data. The consequence of not in- cluding headers would be, e.g., that on HEAD requests you would seem to never make any progress. Yes, I agree that this is somewhat unfortunate. Though in reality I doubt that it will matter much since headers are usually small enough that you don't really need progress reports on them. Well, until you get some mobile network crawling along sending an accept header ... Seriously, this is the sort of problem that makes me want to define this as application-specific. Because it makes no sense to me that a GET request counts the returned header as content, but it makes sense to me that a HEAD request does, and I am not sure what makes sense for PUT. Using it for mail, where you are transferring an entire mailbox as a single object it seems natural to count the mail headers, but shifting an individual message I am not so sure... Is anyone ever going to be able to get any useful size data for the headers anyway though? I.e. if we allow headers to be counted as part of the size, is anyone ever going to be able to do that? To be able to do that you'd have to have some sort of out-of-band metadata that travells parallel to the TCP/IP connection since the TCP/IP connection is busy transferring HTTP which doesn't contain this information. I guess you could use just the 'bytes downloaded so far' part just to show that progress is made, but that would mix very strangly if you then received a body which you did have a size for. Anyhow, I guess I don't care that much about this as it won't affect any actual implementations for the web at least for now. And I think in reality most people will not include the headers due to all the strangness mentioned above if you did include the headers. So feel free to go ahead either way on this. / Jonas
Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
* Jonas Sicking wrote: Is anyone ever going to be able to get any useful size data for the headers anyway though? I.e. if we allow headers to be counted as part of the size, is anyone ever going to be able to do that? To be able to do that you'd have to have some sort of out-of-band metadata that travells parallel to the TCP/IP connection since the TCP/IP connection is busy transferring HTTP which doesn't contain this information. I guess you could use just the 'bytes downloaded so far' part just to show that progress is made, but that would mix very strangly if you then received a body which you did have a size for. You do not know the length of the header while you are reading it, and you may not know the length of the body while reading it. In both cases you would signify that the length is not computable and only report the amout that has been transferred so far. If the length of the body is known, you would signify that after reading the header, and set total to the length of the message (header + rest) that has been read so far. Do note that e.g. with Transfer-Encoding:chunked you do not know the length of the body until you finished reading it. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
Bjoern Hoehrmann wrote: * Jonas Sicking wrote: It makes no sense to me to for HTTP say that the total number of bytes should include HTTP headers. It would be similar to including the TCP headers in the IP packets IMHO. There is a big difference here, an application might not have meaningful access to the latter, but would necessarily have meaningful access to the former (even if only to the next hop). I don't see how ability to get hold of one or another makes a difference in determining whether it's the right or the wrong data. There is lots of data available that would be the wrong data, that doesn't change the fact that it's the wrong data. The consequence of not in- cluding headers would be, e.g., that on HEAD requests you would seem to never make any progress. Yes, I agree that this is somewhat unfortunate. Though in reality I doubt that it will matter much since headers are usually small enough that you don't really need progress reports on them. / Jonas
Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
* Jonas Sicking wrote: It makes no sense to me to for HTTP say that the total number of bytes should include HTTP headers. It would be similar to including the TCP headers in the IP packets IMHO. There is a big difference here, an application might not have meaningful access to the latter, but would necessarily have meaningful access to the former (even if only to the next hop). The consequence of not in- cluding headers would be, e.g., that on HEAD requests you would seem to never make any progress. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
* Anne van Kesteren wrote: Yeah, I'd very much prefer the Progress Events specification to handle this so that not all other specifications using the Progress Events specification need to do so. I agree that a protocol agnostic design would be good, but that indeed doesn't preclude saying what should happen in the HTTP case. Then you should probably file a separate issue on this. It seems to me though that saying much beyond that this is implementation-defined would be misleading to authors, e.g., they might hardcode progress values in their application and get very different values from the implementation, breaking their application. This could happen e.g. if the user is behind a proxy that rewrites the content in some way, or if there are errors in the transmission (the browser may have attempted to pipeline several in- dependent requests and has to retry them later due to a buggy server). If not specified in elaborate detail, the specification should of course highlight very explicitly that authors should not rely on the accuracy of the numbers in any way. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
