(४१३) विनती बहुत बड़ी | uploadReadAheadSize

Question

मैंने .NET 4.0 के साथ एक WCF सेवा लिखी है, जिसे x64IIS 7.5 के साथ मेरे विंडोज 7 अल्टीमेट सिस्टम पर होस्ट किया गया है । सेवा विधियों में से एक में तर्क के रूप में एक 'ऑब्जेक्ट' है और मैं एक बाइट [] भेजने की कोशिश कर रहा हूं जिसमें एक तस्वीर है। जब तक इस चित्र का फ़ाइल आकार कम है तब तक लगभग। 48KB, सब ठीक हो जाता है। लेकिन अगर मैं एक बड़ी तस्वीर अपलोड करने की कोशिश कर रहा हूं, तो WCF सेवा एक त्रुटि लौटाती है: (413) Request Entity Too Large. इसलिए मैंने जो 3 घंटे बिताए हैं, वह त्रुटि संदेश को प्राप्त करता है और इस विषय के बारे में मैंने जो भी विषय देखा है, वह 'uploadReadAheadSize' संपत्ति बढ़ाने का सुझाव देता है। तो मैंने जो किया है वह निम्न कमांड (10485760 = 10MB) का उपयोग कर रहा है:

"appcmd.exe set config -section:system.webserver/serverruntime/uploadreadaheadsize: 10485760 /commit:apphost"

"cscript adsutil.vbs set w3svc/<APP_ID>/uploadreadaheadsize 10485760"

मैंने साइट खोलने और प्रबंधन के तहत "कॉन्फ़िगरेशन संपादक" पर जाकर मान सेट करने के लिए IIS प्रबंधक का उपयोग किया है। दुर्भाग्य से मैं अभी भी रिक्वेस्ट एंटिटी बहुत बड़ी त्रुटि प्राप्त कर रहा हूं और यह वास्तव में निराशाजनक है!

तो क्या किसी को पता है कि मैं इस त्रुटि को ठीक करने के लिए और क्या प्रयास कर सकता हूं?

Comments

10485760 = 10 एमबी, 1 एमबी नहीं

— शॉन रोवन

Answer 1

यह IIS की समस्या नहीं है बल्कि WCF की समस्या है। बड़े संदेशों के साथ सेवा हमले से इनकार करने के लिए WCF डिफ़ॉल्ट सीमा संदेशों को 65KB तक सीमित करता है। अगर आप MTOM का उपयोग नहीं करते हैं तो यह बाइट [] को बेस 64 एनकोडेड स्ट्रिंग (आकार में 33% वृद्धि) => 48KB * 1,33 = 64KB भेजता है

इस समस्या को हल करने के लिए आपको बड़े संदेशों को स्वीकार करने के लिए अपनी सेवा को फिर से कॉन्फ़िगर करना होगा। इस समस्या ने पहले 400 खराब अनुरोध त्रुटि को निकाल दिया लेकिन नए संस्करण में WCF ने 413 का उपयोग करना शुरू कर दिया जो इस प्रकार की त्रुटि के लिए सही स्थिति कोड है।

आपको maxReceivedMessageSizeअपने बंधन में सेट करने की आवश्यकता है । आपको सेट करने की भी आवश्यकता हो सकती है readerQuotas।

<system.serviceModel>
  <bindings>
    <basicHttpBinding>
      <binding maxReceivedMessageSize="10485760">
        <readerQuotas ... />
      </binding>
    </basicHttpBinding>
  </bindings>  
</system.serviceModel>

Comments

मैंने अधिकतम मान सेट किया है। ऊपर दिए गए मान पर क्लिक करें लेकिन फिर भी मुझे वही त्रुटि मिलती है .. रिक्वेस्ट एंटिटी बहुत बड़ी है ..

— सैंडपेक

@ सांडेपेकु - बस के मामले में ... मुझे काफी समय से यही समस्या थी, और तब महसूस हुआ कि मैंने बाइंडिंग नाम का गलत इस्तेमाल किया है, इसलिए WCF अपने कॉन्फिग वैल्यू के बजाय डिफॉल्ट मान का इस्तेमाल कर रहा था, और मुझे सटीक बता रहा था वही त्रुटि।

— एड्रियन कैर

मैंने अधिकतम मान सेट किया है। ऊपर दिए गए मान को देखें लेकिन फिर भी मुझे वही त्रुटि मिलती है .. अनुरोध इकाई बहुत बड़ी है। बंधन नाम खाली नहीं है। मदद!

— नेटसाइड

धन्यवाद सर, यह मददगार था! MaxReceivedMessageSize के लिए एक नया मान सेट करने के लिए maxBufferSize के लिए समान मान सेट करने की आवश्यकता होती है।

— DiligentKarma

@Sandepku यदि आप REST के लिए वेबहॉटबाइंडिंग का उपयोग कर रहे हैं, तो आपको बाइंडिंग नाम बनाने की आवश्यकता हो सकती है <बाइंडिंग> बाइंडिंगफिगरेशन के बराबर <एंडपॉइंट>

— smoothumut

Answer 2

मैं WISF REST सेवा के साथ IIS 7.5 के साथ एक ही मुद्दा रहा था। 65k से ऊपर किसी भी फाइल को POST के माध्यम से अपलोड करने की कोशिश की जा रही है और यह त्रुटि 413 "रिक्वेस्ट एंटिटी बहुत बड़ी" को लौटा देगा।

पहली बात जो आपको समझने की जरूरत है कि आपने web.config में किस तरह का बाइंडिंग कॉन्फ़िगर किया है। यहाँ एक महान लेख है ...

BasicHttpBinding बनाम WsHttpBinding बनाम WebHttpBinding

यदि आपके पास REST सेवा है तो आपको इसे "webHttpBinding" के रूप में कॉन्फ़िगर करने की आवश्यकता है। यहाँ तय है:

<system.serviceModel>

<bindings>
   <webHttpBinding>
    <binding 
      maxBufferPoolSize="2147483647" 
      maxReceivedMessageSize="2147483647" 
      maxBufferSize="2147483647" transferMode="Streamed">
    </binding>  
   </webHttpBinding>
</bindings>

Comments

धन्यवाद, इसने मेरे लिए WISF REST सेवा के साथ IIS 7.5 का उपयोग किया। वास्तव में, मुझे केवल maxReceivedMessageSize विशेषता को संशोधित करना था।

— एलेक्स यूल

मेरे पास maxReceivedMessageSize था, maxBufferSize ने चाल चली, maxBufferPoolSize ने एक अमान्य विशेषता के रूप में दिखाया।

— JabberwockyDecompiler

सुनिश्चित करें कि आप बाइंडिंग नाम को परिभाषित करते हैं और समापन बिंदु पर बाइंडिंगफिगरेशन के बराबर बनाते हैं। Ex: <बाइंडिंग नाम = "restLargeBinding" maxBufferPoolSize = ..........>। और सेवा विन्यास में; <समापन का पता = "" बाइंडिंग = "webHttpBinding" बाइंडिंगऑनफिगरेशन = "रेस्टलेरबाइंडिंग" .......

— स्मूथमूट

महान काम करता है, हालांकि ट्रांसफ़र सेट करना = "स्ट्रीम किए गए" ने मुझे एक बुरा अनुरोध दिया, उस एक को हटाना पड़ा

— WtFudgE

@smoothumut मुझे पता है कि यह पुराना है, लेकिन बाइंडिंगफिगरेशन = "restLargeBinding" ने मेरे लिए चाल चली! वैसे मैं स्वयं होस्टेड wcf सेवा का उपयोग कर रहा हूँ।

— ramires.cabral

Answer 3

मेरे पास एक ही समस्या थी और uploadReadAheadSizeइसे हल करना:

http://www.iis.net/configreference/system.webserver/serverruntime

"मान 0 और 2147483647 के बीच होना चाहिए।"

यदि आप cmd-thing नहीं करना चाहते हैं तो इसे आसानी से applicationHost.config-fle में सेट कर दिया जाता है।

WindowsFOLDER\System32\inetsrv\config(2008 सर्वर) में स्थित है ।

आपको इसे नोटपैड के साथ खोलना होगा। पहले फ़ाइल का बैकअप लें।

कॉन्फ़िगरेशन में टिप्पणियों के अनुसार वर्गों को अनलॉक करने के लिए अनुशंसित तरीका स्थान टैग का उपयोग करके है:

<location path="Default Web Site" overrideMode="Allow">
    <system.webServer>
        <asp />
    </system.webServer>
</location>"

तो आप नीचे में लिख सकते हैं (क्योंकि यह पहले मौजूद नहीं है)। मैं maxvalueयहाँ लिखता हूँ - यदि आप चाहें तो अपना मूल्य लिखें।

<location path="THENAMEOFTHESITEYOUHAVE" overrideMode="Allow">
    <system.webServer>
        <asp />
        <serverRuntime uploadReadAheadSize="2147483647" />
    </system.webServer>
</location>

यदि आप इसे </configuration>उदाहरण के लिए आखिरी बार रखते हैं , तो आप जानते हैं कि आपके पास यह कहां है।

आशा है कि आपकी समस्याओं को हल करता है। यह मेरे लिए एक SSL ओवरहेड मुद्दा था, जहां बहुत अधिक पोस्ट ने एप्लिकेशन को फ्रीज कर दिया, (413) रिक्वेस्ट एंटिटी टू लार्ज एरर को बढ़ा दिया ।

Comments

पहले से ही maxReceivedMessageSizeint.MaxValue में सेट होने के बाद , यह चाल चली। मुझे आश्चर्य है कि क्या int.axValue के लिए भी इस विकल्प को स्थापित करने के साथ कोई बड़ी चिंताएं हैं?

— लैंगडन

क्या किसी को पता होगा कि uploadReadAheadSize, स्वयं होस्टेड WCF सेवाओं के लिए भी प्रासंगिक है, IIS के माध्यम से नहीं चल रही है? यानी यह भी सामान्य रूप से विंडोज सर्वर से जुड़ा मुद्दा है?

— एंटोकोड 14

@antscode मेरे पास एक स्वयं की मेजबानी की गई एपीआई है और उसी समस्या को झेल रही है - क्या आपने इसे अपनी स्वयं की होस्ट की गई सेवा के साथ हल किया है?

— ट्रेवर डैनियल

Answer 4

मुझे यह त्रुटि संदेश प्राप्त हो रहा था, भले ही maxमेरे WCF सेवा विन्यास फाइल के बंधन के भीतर सेटिंग थी।

<basicHttpBinding>
        <binding name="NewBinding1"
                 receiveTimeout="01:00:00"
                 sendTimeout="01:00:00"
                 maxBufferSize="2000000000"
                 maxReceivedMessageSize="2000000000">

                 <readerQuotas maxDepth="2000000000"
                      maxStringContentLength="2000000000"
                      maxArrayLength="2000000000" 
                      maxBytesPerRead="2000000000" 
                      maxNameTableCharCount="2000000000" />
        </binding>
</basicHttpBinding>

ऐसा लग रहा था कि ये बाध्यकारी सेटिंग्स लागू नहीं की जा रही थीं, इस प्रकार निम्न त्रुटि संदेश:

IIS7 - (413) सेवा से जुड़ने पर अनुरोध इकाई बहुत बड़ी।

।

समस्या

मैंने महसूस किया कि name=""भीतर विशेषता <service>के टैग web.configहै नहीं एक नि: शुल्क पाठ क्षेत्र, के रूप में मैंने सोचा कि यह किया गया था। यह इस अनुबंध पृष्ठ के अनुसार उल्लेखित सेवा अनुबंध के कार्यान्वयन का पूरी तरह से योग्य नाम है ।

यदि वह मेल नहीं खाता है, तो बाध्यकारी सेटिंग्स लागू नहीं की जाएंगी!

<services>
  <!-- The namespace appears in the 'name' attribute -->
  <service name="Your.Namespace.ConcreteClassName">
    <endpoint address="http://localhost/YourService.svc"
      binding="basicHttpBinding" bindingConfiguration="NewBinding1"
      contract="Your.Namespace.IConcreteClassName" />
  </service>
</services>

मुझे आशा है कि किसी को कुछ दर्द बचाता है ...

Comments

इस समाधान को जोड़ने के लिए धन्यवाद! अप्रत्यक्ष रूप से मेरी समस्या हल हो गई कि मेरा अनुबंध नाम देव में बदल गया, लेकिन बदलाव को ठीक से उत्पादन के लिए तैनात नहीं किया गया था। इन सेटिंग को चेक करने से मेरी (413) रिक्वेस्ट एंटिटी टू रिलेटेड मैसेज साइज़ सेटिंग्स का उपयोग करने के कारण बड़ी त्रुटियां हुईं।

— डग नूड्सन

मुझे वास्तव में खुशी है कि इसने किसी की मदद की। मैंने इस पर अच्छा समय बिताया इसलिए मुझे उम्मीद थी कि यह किसी के दिन को कम दर्दनाक बना देगा।

— ल्यूक

Answer 5

यदि आप इस थ्रेड के सभी समाधानों की कोशिश करने के बावजूद इस समस्या में भाग ले रहे हैं, और आप SSL (उदाहरण के लिए https) के माध्यम से सेवा से जुड़ रहे हैं, तो यह इस प्रकार हो सकता है:

http://forums.newatlanta.com/messages.cfm?threadid=554611A2-E03F-43DB-92F996F4B6222BC0&#top

सारांशित करने के लिए (यदि भविष्य में लिंक की मृत्यु हो जाती है), यदि आपके अनुरोध काफी बड़े हैं तो क्लाइंट और सेवा के बीच प्रमाणपत्र बातचीत बेतरतीब ढंग से विफल हो जाएगी। ऐसा होने से रोकने के लिए, आपको अपने SSL बाइंडिंग पर एक निश्चित सेटिंग सक्षम करनी होगी। अपने IIS सर्वर से, यहां आपको वे कदम उठाने होंगे जो आपको लेने होंगे:

1. Cmd या शक्तियां, चलाएं netsh http show sslcert। यह आपको अपना वर्तमान कॉन्फ़िगरेशन देगा। आप इसे किसी तरह बचाना चाहेंगे ताकि आप इसे बाद में फिर से संदर्भित कर सकें।
2. आपको ध्यान देना चाहिए कि "Negotiate क्लाइंट प्रमाणपत्र" अक्षम है। यह समस्या सेटिंग है; निम्नलिखित चरणों को प्रदर्शित करना होगा कि इसे कैसे सक्षम किया जाए।
3. दुर्भाग्य से मौजूदा बाइंडिंग को बदलने का कोई तरीका नहीं है; आपको इसे हटाना होगा और इसे फिर से जोड़ना होगा। चलाएं netsh http delete sslcert <ipaddress>:<port>जहां <ipaddress>:<port>IP है: आपके द्वारा पहले सहेजे गए कॉन्फ़िगरेशन में दिखाया गया पोर्ट।
4. अब आप बाइंडिंग को फिर से जोड़ सकते हैं। आप netsh http add sslcert यहां (MSDN) के लिए मान्य पैरामीटर देख सकते हैं लेकिन ज्यादातर मामलों में आपकी कमांड इस तरह दिखाई देगी:

netsh http add sslcert ipport=<ipaddress>:<port> appid=<application ID from saved config including the {}> certhash=<certificate hash from saved config> certstorename=<certificate store name from saved config> clientcertnegotiation=enable

यदि आपके पास कई SSL बाइंडिंग हैं, तो आप उनमें से प्रत्येक के लिए प्रक्रिया दोहराएंगे। उम्मीद है कि यह किसी और घंटे और सिरदर्द को बचाने में मदद करता है इस मुद्दे ने मुझे परेशान किया।

संपादित करें: मेरे अनुभव में, आप वास्तव netsh http add sslcertमें कमांड लाइन से कमांड को सीधे नहीं चला सकते हैं। आपको पहले टाइप करके netsh प्रॉम्प्ट दर्ज करना होगा netshऔर फिर http add sslcert ipport=...काम करने के लिए अपना आदेश जारी करना होगा।

Comments

पोस्ट के लिए धन्यवाद, इसने हमारे लिए समस्या को अलग करने में मदद की, एसएसएल को बंद करने से डब्ल्यूसीएफ की त्रुटि दूर हो जाती है। दुर्भाग्य से क्लाइंटक्रैटनोटेशन ने एसएसएल पर काम करने के लिए हमारे परिणाम को नहीं बदला। टॉगल करने के लिए अन्य बिट्स की तलाश करें:

— जाफिन

Answer 6

इससे मुझे समस्या को हल करने में मदद मिली (एक पंक्ति - पठनीयता / प्रतिलिपि-क्षमता के लिए विभाजन):

C:\Windows\System32\inetsrv\appcmd  set config "YOUR_WEBSITE_NAME" 
     -section:system.webServer/serverRuntime /uploadReadAheadSize:"2147483647" 
     /commit:apphost

Comments

क्या आप अपने WCF को SharePoint वातावरण में होस्ट कर रहे हैं? और क्या आपको परिवर्तनों को लागू करने के बाद अपने IIS को पुनरारंभ करना होगा?

— आईटहॉवॉव

Answer 7

मेरे लिए, uploadReadAheadSizeint.axValue पर सेटिंग करना भी समस्या को ठीक करता है, WCF बाइंडिंग पर सीमाएं बढ़ाने के बाद भी।

ऐसा लगता है कि, एसएसएल का उपयोग करते समय, संपूर्ण अनुरोध इकाई निकाय प्रीलोडेड है, जिसके लिए यह मेटाबेस संपत्ति का उपयोग किया जाता है।

अधिक जानकारी के लिए, देखें:

पृष्ठ प्रदर्शित नहीं किया गया था क्योंकि अनुरोध इकाई बहुत बड़ी है। IIS7

Comments

SSL और 'uploadReadAheadSize' के बारे में आपकी खोज बहुत अच्छी है! .. लेकिन मैं इसे अधिकतम मूल्य पर सेट करने की अनुशंसा नहीं करता हूं

— शिक्षार्थी

Answer 8

IIS WCF त्रुटि 413 की तलाश में किसी और के लिए: शेयरपॉइंट में WCF सेवा को बड़े और उपयोग करने के लिए इकाई का अनुरोध करें, यह आपके लिए जानकारी है। अन्य साइटों / पोस्टों में सुझाए गए एप्लिकेशन होस्ट और web.config की सेटिंग्स SharePoint में काम नहीं करती हैं यदि एकाधिकबेससेड्रेसबासिकहेटपॉइंटबाइंडिंग सर्विससेवनस्टॉफ़ का उपयोग किया जाता है। आप SPWebService.Content सेवा प्राप्त करने के लिए SP Powershell का उपयोग कर सकते हैं, एक नई SPWcvSettings ऑब्जेक्ट बना सकते हैं और अपनी सेवा के लिए उपरोक्त सेटिंग्स को अपडेट कर सकते हैं (वे मौजूद नहीं होंगे)। सेटिंग बनाते और जोड़ते समय बस सेवा के नाम (जैसे [yourervice.svc]) का उपयोग करना याद रखें। अधिक जानकारी के लिए इस साइट को देखें https://robertsep.wordpress.com/2010/12/21/set-maximum-upload-filesize-sharepoint-wcf-service

Answer 9

मेरे मामले में मुझे BizTalk में प्राप्त स्थान का "अधिकतम प्राप्त संदेश आकार" बढ़ाना पड़ा। यह भी 64K का एक डिफ़ॉल्ट मान है और इसलिए हर संदेश को BizTAlk द्वारा बाउंस किया गया था, भले ही मैंने अपने वेब में कॉन्फ़िगर किया हो।

Answer 10

मैं एक ही wcf चैनल / क्लाइंट पर बड़ी सामग्री के अनुरोध के ठीक पहले एक डमी कॉल (जैसे IsAlive रिटर्निंग ट्रू) निष्पादित करके इसे हल करने में सक्षम रहा हूं। पहले कॉल पर स्पष्ट रूप से ssl बातचीत की जाती है। तो Uploadreadaheadsize को बढ़ाने की कोई आवश्यकता नहीं है।

Answer 11

समस्या के लिए रिमोट सर्वर ने अप्रत्याशित प्रतिक्रिया दी: (413) रिक्वेस्ट के साथ डब्ल्यूसीएफ पर रिक्वेस्ट एंटिटी टू लार्ज

कृपया मेरी व्याख्या कॉन्फ़िगरेशन देखें

</client>
<serviceHostingEnvironment multipleSiteBindingsEnabled="false" aspNetCompatibilityEnabled="true"/>

<bindings>

   <!-- this for restfull service -->
  <webHttpBinding>
    <binding name="RestfullwebHttpBinding"
      maxBufferPoolSize="2147483647"
      maxReceivedMessageSize="2147483647"
      maxBufferSize="2147483647" transferMode="Streamed">

      <readerQuotas 
        maxDepth="2147483647" 
        maxStringContentLength="2147483647"
        maxArrayLength="2147483647" 
        maxBytesPerRead="2147483647" /> 

    </binding>
  </webHttpBinding>
  <!-- end -->

   <!-- this for Soap v.2 -->
  <wsHttpBinding>
    <binding name="wsBinding1" maxReceivedMessageSize="2147483647" closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2147483647" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
      <reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false"/>
      <!--UsernameToken over Transport Security-->
      <security mode="TransportWithMessageCredential">
        <message clientCredentialType="UserName" establishSecurityContext="true"/>
      </security>
    </binding>
  </wsHttpBinding>
   <!-- this for restfull service -->

   <!-- this for Soap v.1 -->
  <basicHttpBinding>
    <binding name="basicBinding1" maxReceivedMessageSize="2147483647" closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2147483647" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false" transferMode="Streamed">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
      <security mode="None"/>
    </binding>
  </basicHttpBinding>
</bindings> 
<!-- end -->

<services>
  <clear/>

  <service name="ING.IWCFService.CitisecHashTransfer"  >
    <endpoint address="http://localhost:8099/CitisecHashTransfer.svc"
                  behaviorConfiguration="RestfullEndpointBehavior"
                  binding="webHttpBinding"
                  bindingConfiguration="RestfullwebHttpBinding"
                  name="ICitisecHashTransferBasicHttpBinding"
                  contract="ING.IWCFService.ICitisecHashTransfer" />
  </service>

</services>
<behaviors>
  <serviceBehaviors>
    <behavior name="ServiceBehavior">
      <serviceMetadata httpsGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="true"/>
      <dataContractSerializer maxItemsInObjectGraph="2147483647"/>

      <serviceCredentials>
        <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="ING.IWCFService.IWCFServiceValidator, ING.IWCFService"/>
      </serviceCredentials>
      <serviceSecurityAudit auditLogLocation="Application" serviceAuthorizationAuditLevel="SuccessOrFailure" messageAuthenticationAuditLevel="SuccessOrFailure"/>
      <serviceThrottling maxConcurrentCalls="1000" maxConcurrentSessions="100" maxConcurrentInstances="1000"/>

    </behavior>
    <behavior>
      <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="true"/>
      <dataContractSerializer maxItemsInObjectGraph="2147483647"/>
    </behavior>
  </serviceBehaviors>
  <endpointBehaviors>
    <behavior name="EndpointBehavior">
      <dataContractSerializer maxItemsInObjectGraph="2147483647" />
    </behavior> 
    <behavior name="RestfullEndpointBehavior">
      <dataContractSerializer maxItemsInObjectGraph="2147483647"  />
      <webHttp/>
    </behavior> 
  </endpointBehaviors>
</behaviors>

Answer 12

मेरे मामले में, मुझे यह त्रुटि संदेश मिल रहा था क्योंकि मुझे सेवा का नामस्थान बदल दिया गया था और सेवाओं के टैग को पुराने नाम स्थान पर इंगित किया गया था। मैंने नाम स्थान और त्रुटि को ताज़ा किया:

<services>
  <service name="My.Namespace.ServiceName"> <!-- Updated name -->
    <endpoint address="" 
              binding="wsHttpBinding" 
              bindingConfiguration="MyBindingConfiguratioName" 
              contract="My.Namespace.Interface" <!-- Updated contract -->
    />
  </service>
</services>

Answer 13

Visual Studio 2017 के साथ IIS एक्सप्रेस पर समान त्रुटि मिली।

HTTP एरर 413.0 - एंटिटी का अनुरोध बहुत बड़ा है

पृष्ठ प्रदर्शित नहीं किया गया था क्योंकि अनुरोध इकाई बहुत बड़ी है।

सर्वाधिक संभाव्य कारण:

• वेब सर्वर अनुरोध को सेवा देने से इनकार कर रहा है क्योंकि अनुरोध इकाई बहुत बड़ी है।

• वेब सर्वर अनुरोध को सेवा नहीं दे सकता है क्योंकि यह क्लाइंट प्रमाणपत्र के लिए बातचीत करने की कोशिश कर रहा है लेकिन अनुरोध इकाई बहुत बड़ी है।

• URL या URL के लिए भौतिक मानचित्रण (यानी, URL की सामग्री के लिए भौतिक फ़ाइल सिस्टम पथ) बहुत लंबा है।

वे चीजें जो आप आज़मा सकते हैं:

• सत्यापित करें कि अनुरोध मान्य है।

• क्लाइंट प्रमाणपत्रों का उपयोग करते समय, कोशिश करें:

  • बढ़ती हुई व्यवस्था ।webServer/serverRuntime@uploadReadAheadSize

  • प्रारंभिक SSL हैंडशेक के भाग के रूप में क्लाइंट प्रमाणपत्रों पर बातचीत करने के लिए अपने SSL समापन बिंदु को कॉन्फ़िगर करें। (netsh http sslcert जोड़ें ... clientcertnegotiation = enable) .vs \ config \ applicationhost .concig।

इसे संपादित करके हल करें \.vs\config\applicationhost.config। स्विच serverRuntimeसे Denyकरने के लिए Allowइस तरह:

<section name="serverRuntime" overrideModeDefault="Allow" />

यदि यह मान संपादित नहीं किया जाता है, तो सेटिंग करते समय आपको इस तरह की त्रुटि मिलेगी uploadReadAheadSize:

HTTP त्रुटि 500.19 - आंतरिक सर्वर त्रुटि

अनुरोधित पृष्ठ तक नहीं पहुंचा जा सकता क्योंकि पृष्ठ के लिए संबंधित कॉन्फ़िगरेशन डेटा अमान्य है।

इस पथ पर इस कॉन्फ़िगरेशन अनुभाग का उपयोग नहीं किया जा सकता है। यह तब होता है जब अनुभाग पैरेंट स्तर पर लॉक होता है। लॉकिंग या तो डिफ़ॉल्ट रूप से होती है (ओवरराइडोडोडेफ़ॉल्ट = "इंकार"), या ओवरराइडमोड = "इंकार" या विरासत के साथ एक स्थान टैग द्वारा स्पष्ट रूप से सेट करें। ऑवरराइड = "झूठा"।

फिर Web.configनिम्नलिखित मूल्यों के साथ संपादित करें :

<system.webServer>
  <serverRuntime uploadReadAheadSize="10485760" />
...

Comments

अगर आप वोट देते हैं, तो कृपया कहें। अन्यथा उत्तर में सुधार करना बहुत कठिन है।

— ओग्लास