Implement caching of HTTP form POST

VERIFIED FIXED in mozilla0.9

Status

()

Core
Document Navigation
P3
critical
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: Scott Furman, Assigned: Radha on family leave (not reading bugmail))

Tracking

({dataloss, perf})

Trunk
mozilla0.9
dataloss, perf
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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.
(Reporter)

Updated

18 years ago
Blocks: 14050

Comment 1

18 years ago
Mass move of all bugs without target milestones to M13.
(Reporter)

Updated

18 years ago
Severity: minor → normal

Comment 2

18 years ago
Bulk move of all Cache (to be deleted component) bugs to new Networking: Cache
component.

Comment 3

18 years ago
Assigning fur's cache bugs to Gordon. He can split them up with davidm.

Updated

18 years ago
Target Milestone: M13 → M14

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 4

18 years ago
I think we can get by without this for beta. Moving to M15. 
Target Milestone: M14 → M15

Updated

18 years ago
Target Milestone: M15 → M16

Comment 5

18 years ago
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17

Updated

18 years ago
Keywords: beta2
Whiteboard: 3d

Updated

18 years ago
Keywords: nsbeta2

Comment 6

18 years ago
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

Comment 7

18 years ago
Putting on [nsbeta2-] radar. Missed the Netscape 6 feature train.  Please set to 
MFuture.
Whiteboard: [nsbeta2+][5/16]3d → [nsbeta2-]3d

Comment 8

18 years ago
*** Bug 34633 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Whiteboard: [nsbeta2-]3d → [nsbeta2-]

Comment 9

17 years ago
this might be blocking law for some of his bugs. Nominating. 
Keywords: nsbeta3

Comment 10

17 years ago
does bug 40867 depend on this?  bug 39957, which used to depend on bug 40867, 
was marked as "fixed except for bug 20843".

Comment 11

17 years ago
cc'ing pollmann and radha as well.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Target Milestone: M17 → Future

Comment 12

17 years ago
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.

Comment 14

17 years ago
:) 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. ***
Blocks: 55055
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

Comment 17

17 years ago
cc self

Updated

17 years ago
OS: Windows NT → All
Target Milestone: Future → mozilla0.9

Comment 18

17 years ago
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

Comment 20

17 years ago
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

Comment 21

17 years ago
dataloss => critical
Severity: normal → critical
Keywords: nsbeta2, nsbeta3
Whiteboard: [nsbeta2-][nsbeta3-]

Comment 22

17 years ago
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.
Blocks: 56346
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.

Comment 25

17 years ago
<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.

Updated

17 years ago
Blocks: 68412

Comment 26

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 28

17 years ago
verified
Status: RESOLVED → VERIFIED

Updated

9 years ago
Component: History: Session → Document Navigation
QA Contact: tever → docshell
You need to log in before you can comment on or make changes to this bug.