[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.


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.



Regards, Thomas Hallgren

_______________________________________________ p2-dev mailing list p2-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/p2-dev