[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] Invalid redirect location
|
Hi Thomas,
Thomas Hallgren wrote:
<stuff deleted>
The result is that the HttpUrlConnection returns a valid readable
InputStream but it is empty for the file in question! So that makes
things even worse. I know for sure that the file isn't empty.
That's unfortunate, but I'm not that surprised as this is a fairly
exotic situation...and may even be a server issue as well (as below).
<stuff deleted>
Shouldn't the (normalized) redirect URL not contain a space? I'm not
sure what the spec says about client handling of redirect URLs, but
I'll take a look. But in any case (whether httpclient is
spec-correct or not), we'll see what we can do to fix/workaround.
I'm not sure either. The header field contains a URL that has a space
in it. Perhaps the server is doing something wrong.
Perhaps so, I haven't looked up the relevant parts of spec yet.
My problem is that I have a customer that wants to replace his old way
of aggregating things using the old Update Manager with our new P2
based aggregator. Apparently the old Update Manager doesn't run into
this issue so his experience is that by switching to P2, things stop
working.
Understood.
The HttpMethodDirector.processRedirectResponse then makes an
attempt to create an URI directly from that response without
converting the space to a %20. The result is the exception below.
Is there any way to get around this problem?
I can think of two ways for us to workaround/handle:
1) Modify/patch httpclient (it might be useful to see if this has
already been done to httpclient, but given that the 3.x stream isn't
being work on any more I sort of doubt it).
2) handle httpclient redirect responses 'manually' within the
httpclient provider and do the normalization (%20 insertion) as a
work-around.
Not sure how to accomplish #2. Do you mean patch the ECF httpclient
provider?
Yes. The httpclient provider has this option set:
HttpClientRetrieveFileTransfer (line 572):
getMethod.setFollowRedirects(true);
This line could be eliminated, and then redirect (http 302 status I
believe), could/would be handled within our GetMethod implementation
directly.
This would also have the positive side effect of being able to deal
fully with bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=280023,
which is from Henrik I believe.
In any case, I suggest you open an enhancement request to handle
redirect manually and we can attach patches, etc to that new bug as well
as connect it with 280023.
Thanks,
Scott
Regards,
Thomas Hallgren
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev