How to fix "gclient" generating HTTP 400 Bad Request

[Soo-Hyun Choi]

Hi all,

(I am not 100% sure if this is right place to ask, but "gclient" is used by WebRTC as a prerequisite, I will try here.)


I am trying to build the sample application (PeerConnection Client/Server) as instructed at http://www.webrtc.org/reference/getting-started .

I've realized that our company uses a proxy that does not allow HTTP used by subversion, which basically forbid to run the necessary command:
$> gclient sync --force

The problem seems to be stem from the proxy that manipulates HTTP header which in turn generate HTTP 400 Bad Request: http://pastebin.com/t9P4UjMG

When I am able to check out code trees manually using subversion, I use HTTPS instead in order to get rid of this problem, rather than checking out HTTP - the proxy is known not to manipulate HTTPS headers. Would there be any way that I can change "gclient" so it could try checking out code base using HTTPS instead of HTTP?


Thanks,
Soo-Hyun

[Soo-Hyun Choi]

Hi all,

I have figured out how to get around this situation.

The root cause of the problem described below email comes from a HTTP
proxy server that cannot handle WebDAV/DeltaV request properly. (Note
that WebDAV/DeltaV is not a standard HTTP request) In this case, one
could use HTTPS request instead of the plain HTTP

"gclient" uses HTTP request by default, but we could change
$WEBRTCHOME/DEPS file to make it use HTTPS.

If you open $WEBRTCHOME/DEPS file, change "googlecode_url",
"chromium_url" to use HTTPS:
"googlecode_url": "https://%s.googlecode.com/svn",
"chromium_trunk" : "https://src.chromium.org/svn/trunk",

and change the following line, too:

"trunk/third_party/jsoncpp/":
"https://jsoncpp.svn.sourceforge.net/svnroot/jsoncpp/trunk/jsoncpp@246",

Overall, DEPS file should look like this - http://pastebin.com/SpcHsuFk

Hope this helps someone who are sitting behind the proxy that doesn't
process non-standard HTTP request packets.

Cheers,
Soo-Hyun

[Ralph Giles]

On 21/09/11 04:19 AM, Soo-Hyun Choi wrote:

> The root cause of the problem described below email comes from a HTTP
> proxy server that cannot handle WebDAV/DeltaV request properly. (Note
> that WebDAV/DeltaV is not a standard HTTP request) In this case, one
> could use HTTPS request instead of the plain HTTP

I've filed https://webrtc-codereview.appspot.com/167003 requesting this
change upstream. I've had some trouble accessing code.google.com over
https in the past, but it seems to be working today, so I think it's
worth trying. We'll see if the other reviewers agree.

Thanks for letting us know about the issue,
-r

[Andrew MacDonald]

Chromium uses http exclusively in their DEPS file. I posted the
question on chromium-dev:
http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/66ec778d290e225f#

I'd prefer to get feedback from their experience before we change our DEPS file.

[Soo-Hyun Choi]

Andrew,

On Thu, Sep 22, 2011 at 13:35, Andrew MacDonald <and...@webrtc.org> wrote:
>
> Chromium uses http exclusively in their DEPS file. I posted the
> question on chromium-dev:
> http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/66ec778d290e225f#
>
> I'd prefer to get feedback from their experience before we change our DEPS file.
>

Thanks for your follow-up message.

As known, WebDAV/DeltaV is not standard HTTP. Therefore, if a proxy is
not configured to support them explicitly, then it is likely that
those HTTP requests aren't going to go through the proxy server,
inhibiting checkout the sources using svn.

Unless we have specific reasons to use http (by default) over https,
I'd like to suggest to change DEPS file (WebRTC and Chromium).

Soo-Hyun

[Soo-Hyun Choi]

Ralph,

On Thu, Sep 22, 2011 at 05:02, Ralph Giles <gi...@mozilla.com> wrote:
>
> I've filed https://webrtc-codereview.appspot.com/167003 requesting this
> change upstream. I've had some trouble accessing code.google.com over https
> in the past, but it seems to be working today, so I think it's worth trying.
> We'll see if the other reviewers agree.

Thanks for filing the issue at the codereview site.

Soo-Hyun