Return-Path: X-Original-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3FA3D18FC6 for ; Tue, 13 Oct 2015 03:21:26 +0000 (UTC) Received: (qmail 53124 invoked by uid 500); 13 Oct 2015 03:21:21 -0000 Delivered-To: apmail-hadoop-hdfs-user-archive@hadoop.apache.org Received: (qmail 52989 invoked by uid 500); 13 Oct 2015 03:21:20 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 52979 invoked by uid 99); 13 Oct 2015 03:21:20 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Oct 2015 03:21:20 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 2F5EEC2C32 for ; Tue, 13 Oct 2015 03:21:20 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.999 X-Spam-Level: **** X-Spam-Status: No, score=4.999 tagged_above=-999 required=6.31 tests=[FSL_HELO_BARE_IP_2=1.999, HTML_MESSAGE=3, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id fQlgY4uwJHqA for ; Tue, 13 Oct 2015 03:21:18 +0000 (UTC) Received: from relayvx11b.securemail.intermedia.net (relayvx11b.securemail.intermedia.net [64.78.52.184]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 7D73220C18 for ; Tue, 13 Oct 2015 03:21:17 +0000 (UTC) Received: from securemail.intermedia.net (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id EF65B53EAE; Mon, 12 Oct 2015 20:21:15 -0700 (PDT) Subject: Re: Http request uri query parameters of the redirected location MIME-Version: 1.0 x-echoworx-msg-id: 78d40991-bab2-46a7-b4c9-a711511c080c x-echoworx-emg-received: Mon, 12 Oct 2015 20:21:15.902 -0700 x-echoworx-action: delivered Received: from 10.254.155.14 ([10.254.155.14]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 729; Mon, 12 Oct 2015 20:21:15 -0700 (PDT) Received: from MBX080-W4-CO-1.exch080.serverpod.net (unknown [10.224.117.101]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id A0E9453EAE; Mon, 12 Oct 2015 20:21:15 -0700 (PDT) Received: from MBX080-W4-CO-2.exch080.serverpod.net (10.224.117.102) by MBX080-W4-CO-1.exch080.serverpod.net (10.224.117.101) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 12 Oct 2015 20:21:14 -0700 Received: from MBX080-W4-CO-2.exch080.serverpod.net ([10.224.117.102]) by mbx080-w4-co-2.exch080.serverpod.net ([10.224.117.102]) with mapi id 15.00.1044.021; Mon, 12 Oct 2015 20:21:14 -0700 From: Chris Nauroth To: "user@hadoop.apache.org" CC: Jingfei Hu Thread-Topic: Http request uri query parameters of the redirected location Thread-Index: AdEFWTBXo+DGPYltQ9m5Jiz2JiC5EAADQYuA Date: Tue, 13 Oct 2015 03:21:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [50.181.140.32] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_D241C5752F520cnaurothhortonworkscom_" --_000_D241C5752F520cnaurothhortonworkscom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Jingfei, Yes, the relevant query parameters are included in the redirect location of= the HTTP 302 response, and this is by design. Many of the curl examples in the WebHDFS documentation use the curl -L opti= on. http://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/WebHDF= S.html Passing the -L option to the curl command will cause it to follow redirects= automatically. We expect this would work correctly, because the redirect = location in the HTTP 302 response has the complete query parameter informat= ion, and curl -L would use this in its subsequent HTTP request. --Chris Nauroth From: Jingfei Hu > Reply-To: "user@hadoop.apache.org" > Date: Monday, October 12, 2015 at 6:53 PM To: "user@hadoop.apache.org" > Cc: Jingfei Hu > Subject: Http request uri query parameters of the redirected location Hi team, I am using WebHDFS rest api to read from and write to HDFS cluster files. I= 've got a minor question when using curl command line to practice some apis= . It's Would the query parameters be appended to the redirected location when crea= ting files or any other apis which needs a redirect? Of course, I tried out. And it seems work in that way. curl -i -X PUT "http://xxx:50070/webhdfs/v1/hellowworld?op=3DCREATE If I put it a &user.name=3Dhadoop, then the redirected location would also = contain such a query parameter. My further question is it's by design or not. Can I make this assumption wh= en writing codes? Thanks, Jingfei --_000_D241C5752F520cnaurothhortonworkscom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello Jingfei,

Yes, the relevant query parameters are included in the redirect locati= on of the HTTP 302 response, and this is by design.

Many of the curl examples in the WebHDFS documentation use the curl -L= option.


Passing the -L option to the curl command will cause it to follow redi= rects automatically.  We expect this would work correctly, because the= redirect location in the HTTP 302 response has the complete query paramete= r information, and curl -L would use this in its subsequent HTTP request.

--Chris Nauroth

From: Jingfei Hu <jingfei_hu@hotmail.com>
Reply-To: "user@hadoop.apache.org" <user@hadoop.apache.org>
Date: Monday, October 12, 2015 at 6= :53 PM
To: "user@hadoop.apache.org" <user@hadoop.apache.org>
Cc: Jingfei Hu <jingfei_hu@hotmail.com>
Subject: Http request uri query par= ameters of the redirected location

Hi team,

I am using WebHDFS rest api to read from and write t= o HDFS cluster files. I’ve got a minor question when using curl comma= nd line to practice some apis.  It’s

 

Would the query parameters be appended to the red= irected location when creating files or any other apis which needs a redire= ct?

 

Of course, I tried out. And it seems work in that wa= y.

 

curl -i -X PUT "http://xxx:50070/webhdfs/v1/hellowworld= ?op=3DCREATE

 

If I put it a &user.name=3Dhadoop, then the redi= rected location would also contain such a query parameter.

 

My further question is it’s by design or not. = Can I make this assumption when writing codes?

 

Thanks,

Jingfei

 --_000_D241C5752F520cnaurothhortonworkscom_--