Discussion:
NS_ERROR_NET_PARTIAL_TRANSFER
Daniel Stenberg
2014-04-22 20:21:55 UTC
Permalink
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.
--
/ daniel.haxx.se
Ehsan Akhgari
2014-04-23 01:30:13 UTC
Permalink
Do we currently return NS_OK from Necko in such circumstances or another
error code?
Post by Daniel Stenberg
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.
Boris Zbarsky
2014-04-23 01:59:07 UTC
Permalink
Post by Ehsan Akhgari
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
Ehsan Akhgari
2014-04-23 02:06:06 UTC
Permalink
Post by Boris Zbarsky
Post by Ehsan Akhgari
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. :(
Patrick McManus
2014-04-23 12:13:41 UTC
Permalink
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.
Post by Ehsan Akhgari
Post by Boris Zbarsky
Post by Ehsan Akhgari
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
https://lists.mozilla.org/listinfo/dev-platform
Boris Zbarsky
2014-04-23 02:36:09 UTC
Permalink
Post by Ehsan Akhgari
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
Loading...