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.
Mass move of all bugs without target milestones to M13.
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.
I think we can get by without this for beta. Moving to M15.
Moving to M17 which is now considered part of beta2.
Putting on [nsbeta2+][5/16] radar. This is a feature MUST complete work by 05/16 or we may pull this feature for PR2.
Putting on [nsbeta2-] radar. Missed the Netscape 6 feature train. Please set to MFuture.
*** Bug 34633 has been marked as a duplicate of this bug. ***
this might be blocking law for some of his bugs. Nominating.
cc'ing pollmann and radha as well.
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
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.
dataloss => critical
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.
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.
Radha, I think we're providing everything you need to fix this bug. Let me know if there's any else we can do.
I think this should be marked fixed. bug 55055 tracks what SH needs to do to use cache for Post results