Return-Path: 
 <users-return-32522-apmail-cxf-users-archive=cxf.apache.org@cxf.apache.org>
X-Original-To: apmail-cxf-users-archive@www.apache.org
Delivered-To: apmail-cxf-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 8B4ED986C
	for <apmail-cxf-users-archive@www.apache.org>;
 Tue, 28 Feb 2012 16:55:52 +0000 (UTC)
Received: (qmail 81374 invoked by uid 500); 28 Feb 2012 16:55:51 -0000
Delivered-To: apmail-cxf-users-archive@cxf.apache.org
Received: (qmail 81279 invoked by uid 500); 28 Feb 2012 16:55:51 -0000
Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@cxf.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@cxf.apache.org>
List-Post: <mailto:users@cxf.apache.org>
List-Id: <users.cxf.apache.org>
Reply-To: users@cxf.apache.org
Delivered-To: mailing list users@cxf.apache.org
Received: (qmail 81271 invoked by uid 99); 28 Feb 2012 16:55:51 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Feb 2012 16:55:51 +0000
X-ASF-Spam-Status: No, hits=0.6 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of sberyozkin@gmail.com
 designates 209.85.214.41 as permitted sender)
Received: from [209.85.214.41] (HELO mail-bk0-f41.google.com) (209.85.214.41)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Feb 2012 16:55:45 +0000
Received: by bkty12 with SMTP id y12so6104958bkt.0
        for <users@cxf.apache.org>; Tue, 28 Feb 2012 08:55:24 -0800 (PST)
Received-SPF: pass (google.com: domain of sberyozkin@gmail.com designates
 10.204.133.220 as permitted sender) client-ip=10.204.133.220;
Authentication-Results: mr.google.com;
 spf=pass (google.com: domain of sberyozkin@gmail.com designates
 10.204.133.220 as permitted sender) smtp.mail=sberyozkin@gmail.com;
 dkim=pass header.i=sberyozkin@gmail.com
Received: from mr.google.com ([10.204.133.220])
        by 10.204.133.220 with SMTP id g28mr10209892bkt.16.1330448124004
 (num_hops = 1);
        Tue, 28 Feb 2012 08:55:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        bh=/8QV65Y0U6DOkmS6hO4ePRFC3uPhO7EXq7G93n/I2vQ=;
        b=vvyTksqpTIxsTecgg146HV2Bxu1WSuE4VhhdQHe8DcmRTRlyt7McD20upAzG9UdZNB
         8uaGPoj8dZN3g4EXILSnBo62oHRkS2J3pDjqkv6r/i6ggOdAJAtsHfelyRcND6X9DkVK
         ACLmYaJr7ldKz8Q9Nsn18FSttDTtWmfYQkiJE=
Received: by 10.204.133.220 with SMTP id g28mr8253497bkt.16.1330448123898;
        Tue, 28 Feb 2012 08:55:23 -0800 (PST)
Received: from [10.36.226.4] ([217.173.99.61])
        by mx.google.com with ESMTPS id
 ut6sm32385143bkb.14.2012.02.28.08.55.22
        (version=SSLv3 cipher=OTHER);
        Tue, 28 Feb 2012 08:55:23 -0800 (PST)
Message-ID: <4F4D06FA.10500@gmail.com>
Date: Tue, 28 Feb 2012 16:55:22 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: Is it possible to prevent the whole content to be uploaded if
 content length is too large ?
References: <1330444595166-5522251.post@n5.nabble.com>
In-Reply-To: <1330444595166-5522251.post@n5.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

On 28/02/12 15:56, mkserkan wrote:
> Here is sample interceptor snippet code :
>
> *	public void handleMessage(Message message) throws Fault {		
> 		Map<String, List&lt;String>>  headers = (Map<String, List&lt;String>>)
> message.get(Message.PROTOCOL_HEADERS);
> 		List<String>  clHeader = headers.get("Content-Length");
> 		int contentLength = 0;
> 		if (clHeader != null&&  clHeader.size()>  0 )
> 			contentLength = new Integer(clHeader.get(0)) ;
> 		
> 		if (contentLength>  5000) {
> 			throw new Fault(new RuntimeException("TOO LARGE CONTENT"));
> 		}
> 	}*
>
> But it doesn't work ? Still all contents are uploaded to server. Is it
> possible via another mechanism like setting jaxws properties ?
>

Set the contextual property "attachment-max-size" to some value (in 
bytes) and you should get HTTP 413 back, possibly 500 in case of JAX-WS

HTH, Sergey

> --
> View this message in context: http://cxf.547215.n5.nabble.com/Is-it-possible-to-prevent-the-whole-content-to-be-uploaded-if-content-length-is-too-large-tp5522251p5522251.html
> Sent from the cxf-user mailing list archive at Nabble.com.