ბრაუზერში NuGet v3 ინდექსის გახსნა არ ამოწმებს პაკეტების ჩამოტვირთვის წვდომას. ინდექსი რესურსების URL-ებს აცხადებს @type-ისა და @id-ის მეშვეობით; მეტამონაცემები და პაკეტის შიგთავსი შეიძლება სხვაგან იყოს ჰოსტილი.

  1. აღდგენის გამოსავალში წაიკითხეთ პირველი წარუმატებელი URL, პაკეტის ID და ვერსია.
  2. შეადარეთ ეს ჰოსტი არხის ინდექსში მოცემულ რესურსების URL-ებს. PackageBaseAddress/3.0.0 იძლევა საფუძველს ვერსიების აღრიცხვისა და პაკეტის ფაილების მიღებისთვის.
  3. ქსელის ადმინისტრატორთან საჭირო გზის განხილვისას ჩართეთ გადამისამართებებიც.

feed.example-ზე არსებული ჰიპოთეტური ინდექსისთვის, რომელიც შიგთავსს packages.example-ზე აცხადებს, პაკეტების სია შეიძლება ჩაიტვირთოს, სანამ არჩეული .nupkg დაბლოკილია. განმეორებითი შესვლის ცდები ამ მოთხოვნებს ეკვივალენტურს არ ხდის. ქეშირებული პაკეტის წარმატება ცოტას ამბობს სხვა დისტანციური შიგთავსის URL-ზე.

მიჰყევით გამოცხადებულ რესურსს ჰოსტის სახელის გამოცნობის ნაცვლად. NuGet მას აღმოაჩენს, რადგან არხის ინფრასტრუქტურა შეიძლება შეიცვალოს; მხოლოდ ინდექსის ჰოსტის ნებართვის წესმა შეიძლება ვერ დაფაროს იგი.

დაახარისხეთ ფაქტობრივი პასუხი: 407 ითხოვს პროქსის ავთენტიფიკაციას, ხოლო პოლიტიკის უარყოფას, წარუმატებელ CONNECT-ს, მიუწვდომელ ჰოსტს ან TLS შეცდომა-ს საკუთარი გამოძიება სჭირდება. მსგავს დიალოგებს შეუძლიათ დამალონ ეს განსხვავებები. მოითხოვეთ წვდომა არხის დოკუმენტირებულ რესურს-ჰოსტებზე და არა დაუკავშირებელი პროდუქტის ფართო ნიშნების სიაზე, შემდეგ გამოიძიეთ დარჩენილი ანგარიშის ხარვეზი.

დაკავშირებული სტატიები