On Mon, Aug 23, 2021 at 11:37 AM Korbinian Bachl <
korbinian.ba...@whiskyworld.de> wrote:

> Hi Jon,
> Hi Martin,
>
> thanks for pointing me there. It would work that way:
>
> getRequestCycle().scheduleRequestHandlerAfterCurrent((requestCycle -> {
>                         WebResponse response = (WebResponse)
> requestCycle.getResponse();
>                         response.setHeader("test", "1");
>                         response.setHeader("Location", targetUrl);
>                         response.setStatus(301);
>                         // response.sendRedirect(targetUrl); -> is only
> 302!
>                     }));
>
>
> the sendRedirect ist always 302, 301 only works with the location header.
> Feels bit "un"wicket to do all this.
> The main goal is to just redirect with 301 to an URL and have some headers
> set - is there any easier/ faster way to do this?


> In times before wicket 8 I had a custom RedirectTarget301 extends
> RedirectRequestTarget for this.
>

You could still do it with:
getRequestCycle().scheduleRequestHandlerAfterCurrent(new
RedirectRequestHandler("...", 301) {
  @Override
  public void respond(IRequestCycle cycle) {
   super.respond(cycle);

   WebResponse response = (WebResponse) cycle.getResponse();
   response.setHeader("test", "1");
  }
}


>
> I've seen the RedirectToUrlException in wicket 8 but that basically just
> wraps the above logic into a super(new RedirectRequestHandler(....)) of
> ReplaceHandlerException.
>
> Would that be the best way to have this solved? A custom
> Redirect301ToUrlException(String targetUrl, Headers... header) ?
>

As with any framework it should be possible to do anything you need than to
have an API for every possible use case out there!

But let's assume we add such "Headers..." parameter.
Should we also add logic to protect the users from doing strange things
like adding caching response headers to a PERMANENT redirect ? What is the
idea behind caching something that should never be there ever again ?!


>
>
> Best,
>
> KB
>
>
>
> ----- Ursprüngliche Mail -----
> > Von: "Martin Grigorov"
> > An: "users" <users@wicket.apache.org>
> > Gesendet: Montag, 23. August 2021 10:03:34
> > Betreff: Re: RedirectRequestHandler and HttpHeader?
>
> > Hi Korbinian,
> >
> > I am not sure this is possible.
> > You could set response headers for normal responses, but not for
> redirects'
> > targets.
> >
> > On Mon, Aug 23, 2021 at 1:41 AM Locke, Jonathan (Luo Shibo) <
> > jonath...@telenav.com> wrote:
> >
> >> It's been a while, but can't you get the WebResponse from
> WebRequestCycle
> >> and then call response.setHeader()?
> >>
> >
> > To continue Jon's idea:
> >
> > getRequestCycle().scheduleRequestHandlerAfterCurrent((requestCycle) -> {
> >   WebResponse response = (WebResponse) requestCycle.getResponse();
> >   response.setHeader(...);
> >   response.setRedirect("...");
> > });
> >
> > Play with it but you should set the headers in the response after the
> > redirect happens.
> >
> > Martin
> >
> >
> >>     Jon
> >>
> >> ________________________________
> >> From: Korbinian Bachl
> >> Sent: Sunday, August 22, 2021 4:58 AM
> >> To: users <users@wicket.apache.org>
> >> Subject: RedirectRequestHandler and HttpHeader?
> >>
> >> Hi,
> >>
> >> I call this:
> >>
> >> getRequestCycle().scheduleRequestHandlerAfterCurrent(new
> >> RedirectRequestHandler("myNewURL",301));
> >>
> >> How could I add a custom HttpHeader to the response?
> >> e.g.: Cache-Control: max-age=300
> >>
> >>
> >> Best,
> >>
> >> KB
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >> [EXTERNAL EMAIL] CAUTION: This email originated from outside of Telenav.
> >> DO NOT CLICK links or attachments unless you recognize the sender and
> know
> >> the content is safe.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Reply via email to