----- Original Message ----- > From: "Robin H. Johnson" <robbat2@xxxxxxxxxx> > To: "Yehuda Sadeh-Weinraub" <yehuda@xxxxxxxxxx> > Cc: ceph-devel@xxxxxxxxxxxxxxx, "Jonathan LaCour" <jonathan.lacour@xxxxxxxxxxxxx> > Sent: Tuesday, June 23, 2015 4:04:49 PM > Subject: Re: RGW S3 Website hosting, non-clean code for early review > > > 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? > One pull request for the full series. Yehuda -- 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
