Re: NS_ERROR_NET_PARTIAL_TRANSFER
I want to highlight why Its also an important change - there is a very real and important error: your channel content is truncated. Its a bug that necko doesn't tell you about that right now. So we're going to fix that up. The download manager is the obvious victim of this right now. It declares some classes of interrupted downloads as OK. You can't use or restart the result. Any channel over TLS that thinks it has integrity (scripts? css? someone's xhr?) because of that can be silently truncated with the current bug. Consumers that want to ignore the error (from the bug that is at least docshell, and Daniel is asking primarily about images here I believe) will need to handle the exception.. There is no change in the amount of data returned.. just OK - NEW_ERROR_CODE. On Tue, Apr 22, 2014 at 10:06 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2014-04-22, 9:59 PM, Boris Zbarsky wrote: On 4/22/14, 9:30 PM, Ehsan Akhgari wrote: Do we currently return NS_OK from Necko in such circumstances or another error code? Currently we return NS_OK, so the necko client thinks the transfer completed successfully. That seems like a huge behavior change. :( ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: NS_ERROR_NET_PARTIAL_TRANSFER
Do we currently return NS_OK from Necko in such circumstances or another error code? On 2014-04-22, 4:21 PM, Daniel Stenberg wrote: Hey all, In the networking team we're about to introduce an error code for partial transfers (see https://bugzilla.mozilla.org/show_bug.cgi?id=237623). It will be returned when the underlying protocol's framing is cut off and we know that the transfer was indeed partial - not all data arrived. Right now the patch in progress returns this value for HTTP 1.1 Content-Length: underrun, cut off chunked-encoding chunks and broken SPDY or http2 streams. While the primary bug report for this identifies a problem in the download manager that makes it not discover cut off transfers and instead signal them as complete, this change will and can have some further impact on other areas of Firefox and I want to highlight this, give you all a heads up and listen in if there are any additional thoughts or feedback on this pending change. The question I think all consumers of protocol data need to ask ourselves is: how should we deal with partial contents? Up until today, we silently just ignored the potential problems and considered whatever we got fine enough to use. Images? Javascript? CSS? Anything else? This change will also make Firefox align with the other browsers that already are stricter in this area. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: NS_ERROR_NET_PARTIAL_TRANSFER
On 4/22/14, 9:30 PM, Ehsan Akhgari wrote: Do we currently return NS_OK from Necko in such circumstances or another error code? Currently we return NS_OK, so the necko client thinks the transfer completed successfully. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: NS_ERROR_NET_PARTIAL_TRANSFER
On 2014-04-22, 9:59 PM, Boris Zbarsky wrote: On 4/22/14, 9:30 PM, Ehsan Akhgari wrote: Do we currently return NS_OK from Necko in such circumstances or another error code? Currently we return NS_OK, so the necko client thinks the transfer completed successfully. That seems like a huge behavior change. :( ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: NS_ERROR_NET_PARTIAL_TRANSFER
On 4/22/14, 10:06 PM, Ehsan Akhgari wrote: That seems like a huge behavior change. :( Yes, it is. There's some at-length discussion in the bug about what behavior various consumers want here. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
