On Tue, Jun 23, 2015 at 04:30:19PM -0400, Yehuda Sadeh-Weinraub wrote: > > Either I have to repeat a lot of code for it, which I'm not happy about, > > or I have to refactor RGWGetObj* to more safely made the second GET > > request for the error object (and make sure range headers etc are NOT > > used for the get of the error object). I'm leaning to the latter. > Is generating a new req_state a possibility? E.g., you catch the error > at the top level, and restart most of the request processing with a > newly created req_state? That was the path I was trying, but not completely succeeding. I think need to step it back further and have a partially customized copy of the RGWEnv from client_io->get_env(), so that I can build the modified req_info for req_state. It isn't a full new GET really, it's really just custom content for the body as well as some headers (mostly Content-Length, Content-Type), but ignore EPERM/EACCESS on trying to fetch that custom content, and if they are detected, consider that a success but with different HTML content. > Great! I'll wait for the cleaned up pull request. Do you want pull requests per logical change of my proposed series split, or rather just one pull request with the full series? -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robbat2@xxxxxxxxxx GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
