Closed Bug 20843 Opened 25 years ago Closed 23 years ago

Implement caching of HTTP form POST

Categories

(Core :: DOM: Navigation, defect, P3)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: fur, Assigned: radha)

References

Details

(Keywords: dataloss, perf) 

The code for caching of form POST responses is very much the same as for caching
responses to HTTP GETs.  The only difference is that the form post data must be
incorporated into the cache key (along with the POST URL).  The
nsINetDataCacheManager::GetCachedNetData() method provides a "secondary key"
argument for precisely this purpose.

The implementation probably goes something like this:
  1) Read all data from post-data stream into string buffer
  2) Hash string buffer to produce a hashcode, e.g. use MD5 hash
  3) Use the hashcode as the secondary cache key
  4) If the cache lookup misses, form data will need to be written to
     the transport stream, so the string produced in step #1 will need
     to be converted back into a stream using nsIStringStream

This technique might not be practical with file upload via multipart/form-data,
since the form data can be huge for that case.  I'm not sure what we do there -
maybe the form upload widget will need to mark the content as not cachable.
Blocks: 14050
Mass move of all bugs without target milestones to M13.
Severity: minor → normal
Bulk move of all Cache (to be deleted component) bugs to new Networking: Cache
component.
Assigning fur's cache bugs to Gordon. He can split them up with davidm.
Target Milestone: M13 → M14
Status: NEW → ASSIGNED
I think we can get by without this for beta. Moving to M15.
Target Milestone: M14 → M15
Target Milestone: M15 → M16
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17
Keywords: beta2
Whiteboard: 3d
Keywords: nsbeta2
Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.
Whiteboard: 3d → [nsbeta2+][5/16]3d
Putting on [nsbeta2-] radar. Missed the Netscape 6 feature train.  Please set to 
MFuture.
Whiteboard: [nsbeta2+][5/16]3d → [nsbeta2-]3d
*** Bug 34633 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta2-]3d → [nsbeta2-]
this might be blocking law for some of his bugs. Nominating.
Keywords: nsbeta3
does bug 40867 depend on this?  bug 39957, which used to depend on bug 40867, 
was marked as "fixed except for bug 20843".
cc'ing pollmann and radha as well.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Target Milestone: M17 → Future
Radha, don't we already store the post data stream in session history?

It doesn't seem like 40867 would depend on storing the post data stream in
session history though - because 40867 says "we shouldn't hit the server again"
and if we store the post data stream (which we already do) it sounds like we're
planning on hitting the server again...
Session History stores the post data stream for each frame. I'm bit confused by 
the rest of the comments that Eric made. I let you experts decide.
:) You can ignore the second part of my comments - senseless rambling...  The 
important point is, I think, that we already do hang on to the data that is 
sent to the server for a form post.
*** Bug 56346 has been marked as a duplicate of this bug. ***
gordon: 56346 has been marked a dupe of this one. Please adjust the Target
milestone as per our discussion. Nominating for mozilla 0.9
Keywords: mozilla0.9
cc self
OS: Windows NT → All
Target Milestone: Future → mozilla0.9
This bug seems related to bug 32293, but I'm not quite sure if it's really a 
dupe. (It seems like that to me, but what do i know.)
If I can help in any way, let me know.

/be
Bug 56346 (dup of this bug) depended on bug 40867.  It seems like this bug 
should depend on bug 40867, or vice-versa.  Cached copies of HTTP POST requests 
will only be used for session history (going back) and doing things with the 
current page (view source, save as), right?

Copying dataloss and perf keywords from dup bug 56346.
Keywords: dataloss, perf
dataloss => critical
Severity: normal → critical
Keywords: nsbeta2, nsbeta3
Whiteboard: [nsbeta2-][nsbeta3-]
Marking bug 56436 widens the scope of this bug a lot. From the other bug:
<quote>
When browsing in session history we should be able to display previous pages
without fetching them again from the network, regardless if they are "cachable"
or not. Therefore *all* pages should be cached, if not in disk cache, then in
memory cache for re-use within the current session when requested by browsing
in session history.
</quote>
More there.
I think, the SUMMARY of this bug is thus too narrow.

Ben, I think it is better to keep the scope of this bug narrow.
But I reopened bug 56436 for the other issues.
No longer blocks: 56346
Bug # in the last 2 comments is wrong. Should be bug 56346.

<http://www.w3.org/TR/2001/NOTE-cuap-20010206>:

1.10 Allow the user to keep track of completed HTTP POST requests.

Users may wish to track and archive HTTP POST requests for the same reasons they
wish to track and archive email. For instance, if the user places a book order
through a form, and that form uses a POST request, the user should be able to
store information about that transaction.
Blocks: 68412
Radha, I think we're providing everything you need to fix this bug.  Let me know 
if there's any else we can do.
Assignee: gordon → radha
Status: ASSIGNED → NEW
Component: Networking: Cache → History: Session
I think this should be marked fixed. bug 55055 tracks what SH needs to do to use 
cache for Post results
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: tever → docshell
Pushed by ecoal95@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b1cccafd336d
No bug - Import style changes from Servo PR #20843. r=me
You need to log in before you can comment on or make changes to this bug.