"Prefer" request header in PageIterator

[WolfgangHG]

You can create a request that fetches a calendar item content as plain text like this:

EventCollectionResponse eventCollResponse = await graphClient.Me.Calendar.Events.GetAsync(
  c =>
  {
    c.Headers.Add("Prefer", "outlook.body-content-type=\"text\"");
  });

You could put this response object in an iterator:

PageIterator<Event, EventCollectionResponse> iterator = PageIterator<Event, EventCollectionResponse>.CreatePageIterator(graphClient, eventCollResponse,
  (eventAktuell) =>
  {
    //Do something....
    return true;
  });

But there, the "Prefer" header is only applied to the first page, the rest of the calendar items returns the html body.

Solution/Workaround: set the header in the iterator instead:

PageIterator<Event, EventCollectionResponse> iterator = PageIterator<Event, EventCollectionResponse>.CreatePageIterator(graphClient, eventCollResponse,
  (eventAktuell) =>
  {
    //Do something....
    return true;
  },
  c =>
  {
    c.Headers.Add("Prefer", "outlook.body-content-type=\"text\"");
  }));

One might expect that the header for the initial request is applied to all pages of the iterator.

What do you think? Is the current behavior expected, or is this something that could be improved? It could either copy headers from the "TCollectionPage" to each page request. Or it could also raise an exception if the "TCollectionPage" contains headers instead of providing them to the iterator itself, as it probably has unexpected results if using it this way.

[andrueastman]

Thanks for raising this @WolfgangHG

It could either copy headers from the "TCollectionPage" to each page request. Or it could also raise an exception if the "TCollectionPage" contains headers instead of providing them to the iterator itself, as it probably has unexpected results if using it this way.

I believe TCollectionPage is typically a model that has a property with the nextlink (only the url that the iterator follows) as well as a List<T> of the individual response items. As the first request is made outside of the context of the PageIterator using the requestConfigurator parameter is what would be expected for now.

[WolfgangHG]

@andrueastman You can close this if you think the current behavior is valid. I just wanted to bring it to your attention - it confused me a bit ;-). It would be helpful if the api could detect that only the first iterator page has a requestConfiguration and throw an exception.