Redenen voor een 409/Conflict HTTP-fout bij het uploaden van een bestand naar sharepoint met behulp van een .NET WebRequest?

Ik heb een methode die een WebRequest gebruikt om een bestand te uploaden naar een sharepoint 2010 lijst/map, met behulp van een PUT-verzoek, met de Overwrite Header ingesteld op T (overwrite).

Wanneer meerdere bestanden worden geüpload (de methode wordt meerdere keren aangeroepen), mislukken sommige verzoeken met een 409 Conflict HTTP-fout.

Ik heb gegoogeld en het lijkt erop dat de meest voorkomende reden is om een bestand te beïnvloeden/bijwerken dat niet bestaat (zoals het instellen van de verzoek-URL naar een pad zonder bestandsnaam). Dat is echter niet het geval. In het geval dat het conflict iets te maken had met het reeds bestaande bestand, heb ik code toegevoegd om het bestand fysiek te verwijderen voordat ik het upload, en ik krijg nog steeds een aantal 409’s.

Heeft iemand dit type fout ontvangen, en zo ja, kunt u me vertellen hoe u dit hebt opgelost en wat de oorzaak was? Alle hulp wordt zeer op prijs gesteld. Bedankt

Antwoord 1, autoriteit 100%

Omdat er geen antwoorden zijn gepost, heb ik het volgende hiergevonden:

De webserver (die de website uitvoert) denkt dat het verzoek dat door de klant is ingediend (bijvoorbeeld uw webbrowser of onze CheckUpDown-robot) niet kan worden voltooid omdat het in strijd is met een reeds vastgestelde regel. U kunt bijvoorbeeld een 409-fout krijgen als u probeert een bestand naar de webserver te uploaden dat ouder is dan het bestand dat er al is, wat resulteert in een versiebeheerconflict.

Iemand met een soortgelijke vraag hier op stackoverflow, zei dat het antwoord was:

Ik heb dit probleem gehad toen ik verwees naar de url van het document
bibliotheek en niet het doelbestand zelf.

d.w.z. probeer http://server name/document library name/new file name.doc

Ik ben er echter 100% zeker van dat dit niet mijn geval was, aangezien ik de URI-eigenschap van de WebRequest verschillende keren heb gecontroleerd en de URI compleet was met de bestandsnaam en alle mappen in het pad op de sharepoint-site stonden.

Hoe dan ook, ik hoop dat dit iemand helpt.

Antwoord 2, autoriteit 9%

Ik vond twee dingen die het vermelden waard zijn tijdens het uploaden van bestanden met webdav en http-webverzoek. Ten eerste moest ik voor de provider die ik gebruikte de bestandsnaam toevoegen aan het einde van de provider-URL. Ik moest het poortnummer in de url toevoegen. En ik heb de Request-methode ook ingesteld op PUT in plaats van POST.

voorbeeld:

string webdavUrl = "https://localhost:443/downloads/test.pdf";
request.Method = "PUT";

Antwoord 3, autoriteit 9%

Soms komt de foutcode 409voor wanneer u uw map of bestanden een gereserveerde of geblokkeerde naam geeft. Dit kunnen namen zijn als register, contact

In mijn geval heb ik een map contactgenoemd, het bleek dat de naam niet als mapnamen kon worden gebruikt.

Bij het testen van mijn script op postmankreeg ik deze foutmelding:

<script>
    document.cookie = "humans_21909=1"; document.location.reload(true)
</script>

Ik heb de mapnaam gewijzigd van contact in contacten en het werkte. De fout was verdwenen.

Antwoord 4, autoriteit 6%

We krijgen ook dezelfde fout terwijl we proberen toegang te krijgen tot dezelfde bron in milliseconden. Zoals wanneer ik probeer om wat gegevens te POSTnaar www.abc.com/blogen binnen milliseconden zal een ander verzoek ook voor dezelfde bron gaan, namelijk www.abc.com/blogvan dezelfde gebruiker. Dus het geeft de 409-fout.

Antwoord 5, autoriteit 6%

Ik kwam een soortgelijk probleem tegen bij het uploaden van een bestand dat 409 geretourneerd heeft.

Naast de hierboven genoemde problemen kan het ook gebeuren als gevolg van bestandsgroottebeperkingen voor POST aan de serverzijde. Tomcat (java-webserver) heeft bijvoorbeeld een POST-groottelimiet van 2 MBstandaard.

Antwoord 6, autoriteit 6%

Ik kreeg deze fout bij het maken van een map http://localhost:8080/repository/ standaard/ouder/nieuwe map
toen http://localhost:8080/repository/default/parentniet bestond.

Antwoord 7

Het komt door een verkeerd opgegeven pad. Het kan zijn dat de url spatie bevat en als de hoofdletter url goed moet worden opgebouwd.

De juiste url moet de indeling hebben waarin de bestandsnaam is opgenomen, zoals “http://servernaam/documentbibliotheeknaam/ nieuwe bestandsnaam”

Dus als report.xlsx het bestand is dat moet worden geüpload naar “http://servernaam/Team/Dev Team” dan blijkt het pad te zijn “http://servernaam/Team/Dev Team/report.xlsx”. Het bevat ruimte, dus het moet worden gereconstrueerd als “http://servername/Team/Dev%20Team/report.xlsx” en moet worden gebruikt.

Antwoord 8

Ik ben dit probleem meerdere keren tegengekomen om verschillende redenen. Ik zal er hier enkele opsommen.

1. De Chrome-browser slaat het verzoek op in de cache. U kunt dit uitschakelen in de Chrome-ontwikkelaarsconsole of in de code de header {cache: 'no-cache'}

   gebruiken

2. Het geneste mappad bestaat niet bij het plaatsen van het bestand. Controleer eerst of de map bestaat voordat u het bestand in de geneste map plaatst.

3. Zowel het nieuwe bestand als de inhoud van het oude bestand zijn (ongeveer) hetzelfde, evenals het commit-bericht. Verander gewoon het commit-bericht om meer willekeurig te zijn. Gebruik zoiets als dit in het commit-bericht.

    const date = new Date()
     const timeStampHash = `${date.toISOString()}-${Math.floor(Math.random() * 1000)}`
     const commitMsg = `Commited from my App: #${timestampHash}`

Antwoord 9

I is omdat je voorgedefinieerde variabelen gebruikt om je bestandsnaam een naam te geven. verander uw bestandsnaam van bijvoorbeeld register.asp naar registerUser.asp. Dat lost je probleem op

Antwoord 10

hernoem a.u.b. de naam van uw bestand of map van API
like- xyz.com/register.php
hernoem het xyz.com/mijnregister.php

een naam, zoekwoord is geblokkeerd bij het krijgen van deze fout