Uploaded image for project: 'Confluence'
  1. Confluence
  2. CONF-24323

Investigate file size restriction enforcement for /wiki/rpc/soap-axis/confluenceservice-v1 / addAttachment API

    Details

    • Last commented by user?:
      true

      Description

      The cause for HOP-314 was the usage of the /wiki/rpc/soap-axis/confluenceservice-v1 / addAttachment API with relatively large files (~82mb). If I recall right, our attachment file size in OnDemand is set to 100mb (CONFDEV-3606), but I've got no idea if it is enforced if using this API and if so it's probably after the deserialisation. The limit wouldn't have mattered anyway in the above mentioned case.

      Please investigate if a limit of 100mb is still feasible (imo it's way too high, I would even suggest reducing it to ~10-15mb) as the production max heap size is 512mb. Please also ensure that the limit is enforced when using the above mentioned API before it's getting deserialised since it'll cause a memory footprint of at least double the size.

      Maybe we should enforce the setting of the Content-length header via a filter for these requests, and enforce the limit via that (even if it's not accurate). We could also experiment with just setting the maxPostSize on the container.

        Issue Links

          Activity

          Hide
          cmiller Charles Miller [Atlassian] added a comment -

          The addAttachment method in SOAP/RPC is really ugly and not something I ever wanted to support in the first place, but customers seem to use it. We should be careful not to break any workflow customers are used to.

          That said, the inefficency of how we deal with attachment data means we should at least have a sensible default.

          Show
          cmiller Charles Miller [Atlassian] added a comment - The addAttachment method in SOAP/RPC is really ugly and not something I ever wanted to support in the first place, but customers seem to use it. We should be careful not to break any workflow customers are used to. That said, the inefficency of how we deal with attachment data means we should at least have a sensible default.
          Hide
          barconati Bill Arconati added a comment -

          Thank you for raising this issue. While I can see how this feature would be useful, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now.

          Thanks again for your idea.

          Bill Arconati,
          Confluence Group Product Manager

          Show
          barconati Bill Arconati added a comment - Thank you for raising this issue. While I can see how this feature would be useful, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now. Thanks again for your idea. Bill Arconati, Confluence Group Product Manager

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Last commented:
                1 year, 2 weeks, 4 days ago