Pairing and Giving Feedback
The Pairing Experience
A little background:
I can work for hours in complete solitude and focus for long periods of time and actually enjoy the process. I also find that most times, when finished it is like coming up for air and I seek out companionship. In many cases to discuss what I have recently learned or designed - my wonderful/poor wife. At the same time I tremendously love working with, being challenged by, being encouraged by, and the exchange of seeing another's perspective and having the opportunity of articulating mine. Both approaches are extremely rewarding and fulfilling. In reviewing the past, I find that I spend about half of my working/creative time in both categories.
DBC Pairing
I have enjoyed working on the challenges and being stretched. It is awesome when an idea/solution comes to mind that is elegant and it is transformed into code, producing the desired affect. However, it is a rush to work with others who have the same goal of revolutionizing their lives and enhancing the lives of those around us.
All of my pairing sessions have been very rewarding, both intellectually and emotional. It is fun to build something with another person, see their point of view. It is also beneficial to have your own idea and then be presented a different idea and see their idea as a linked yet unique in approach. I really like the protocol that DBC has put in place. I find it very freeing and helpful to ask how the other person is doing, to get to share where you are at the moment, to ask how they would like to proceed, and decide on initial driver/navigator roles.
Speaking to vulnerability, in one of my pairings I felt like I was a little off, a bit behind, and kind of slow. This was not fun. I felt at many times like I needed to apologize and did. I also felt like I needed to make it up. I then realized that this happens to all of us and that I was being to hard on myself. This approach improved my performance and our session.
Writing Feedback
Every time I read my feedback, I am a tiny bit nervous - people are critiquing me in an area where I am fairly new. I have received almost all positive feedback, which has worked to encourage me and drive me. I noticed that all people I have worked with, enjoyed working with me. They felt that I listened and offered my opinion. It has also been mentioned that I am curious and enjoy looking for multiple approaches and that it is less about the right way than various ways. I have enjoyed working with all of the people with whom I have paired. I feel like all of the Boots that I have worked with are ready to take it to the next level.
In one feedback, my peer offered the same feedback that he gave himself, that is to "...add a little structure and planning…". Ever since this feedback, I have emailed my pair and asked what specifically they would like to work on or accomplish. I can see the benefits already.
In giving feedback, I have tried very hard to adhere to the Specific, Actionable, and Kind rule.
Specific: The writer should be focused on details instead of generalities
Actionable: The writer should be focused on comments that describe the interaction in such a way that the recipient could take action and work toward change.
Kind: The writer should be focused on the truth, on ways for the recipient to gain wisdom from your words - not just warm feelings.
I enjoyed writing the feedback, because I enjoyed working with each of Boots in my peer-pairing. I am looking forward to working with them in San Francisco.
I did find that to be kind and speak the truth in kindness, without all the niceness required mental discipline. I have worked on using this approach in my daily interactions and have found it to bear fruit.
The Future
I am energized about working with others in San Francisco, however, I wonder if I benefit others as much as I will be benefitted.
Here's to us Boots!


Badges are inline block elements that often are used on top of or close to another component. They can be used with numbers, text and icons. A small badge version also exists which does not support slotted content.
A white badge can easily blend into the background and just appear as a number, icon or not at all if no content is passed. Here it can be necesssary to apply some elevation to the badge; this is also done for the examples below where all the badges are displayed on a white background.
The
--kirby-badge-elevation
property can be useful for this. You can see how it is applied to the examples below by inspecting
the shared styling for the badge examples:
badge-example-shared.scss on Github
Using a badge with a number can be a good way to indicate specific status on an element.
Badges can also be used together with a text. Flags might in some cases be a better alternative.
It is possible to slot an icon to display it in a badge. This might be used to indicate the existence of an associated element (e.g. an attachment).
Setting the input property
size
to
'sm'
will display a small badge without any content. This can be useful to indicate status on an
element.


Hybrid Cooling
SDE4 combines pre-cooled air, with natural and mecahnical air movement to enable occupant comfort at elevated room temperatures.
Adaptive Comfort
SDE4 offers direct control over user's immediate environment through openable windows and adjustable fans speeds, thus helping users adapt to a wider range of thermal conditions.
Mixed Mode
SDE4's hybrid cooling system is a single-pass system that supplies pre-cooled air, at higher temperatures and humidity levels than a conventional system, with additional elevated air speed by ceiling fans.
Enhanced IEQ
SDE4 envelope design optimises natural lighting and cross ventilation and offers scenic views of the sorroudings for building occupants.
Visualisation Tool
This tool uses an experiment to showcase achievement of thermal comfort with a hybrid cooling system using different fan speeds.
SenSING
SenSING provides indoor sensors that help companies solve three big issues in the workplace: energy savings, comfort and wellbeing, efficiency and productivity.


| OLD line(s): 2,5
<xsd:schema targetNamespace="http://www.irs.gov/efile" xmlns="http://www.irs.gov/efile" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> | NEW line(s): 2
<xsd:schema xmlns="http://www.irs.gov/efile" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.irs.gov/efile" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> |
| OLD line(s): 9
<TaxYear>2012</TaxYear> | NEW line(s): 6
<TaxYear>2013</TaxYear> |
| OLD line(s): 14,17
<xsd:include schemaLocation="../../../Common/efileTypes.xsd" /> | NEW line(s): 11
<xsd:include schemaLocation="../../../Common/efileTypes.xsd"/> |
| OLD line(s): 21,22
| NEW line(s): 14
|
| OLD line(s): 44
| NEW line(s): 35
|
| OLD line(s): 50
| NEW line(s): 40
|
| OLD line(s): 52
<xsd:element name="DescOfPropertyBeingChangedInfo" type="DescOfPropertyBeingChangedInfoType" minOccurs="0" maxOccurs="unbounded"> | NEW line(s): 42
<xsd:element name="DescOfPropertyBeingChgdInfoGrp" type="DescOfPropertyBeingChgdInfoGrpType" minOccurs="0" maxOccurs="unbounded"> |
| OLD line(s): 59
| NEW line(s): 48
|
| OLD line(s): 62,63
<xsd:complexType name="DescOfPropertyBeingChangedInfoType"> | NEW line(s): 51
<xsd:complexType name="DescOfPropertyBeingChgdInfoGrpType"> |
| OLD line(s): 68
| NEW line(s): 55
|
| OLD line(s): 70
<xsd:element name="TypeOfProperty" type="ShortDescriptionType" minOccurs="0"> | NEW line(s): 57
<xsd:element name="PropertyDesc" type="ShortDescriptionType" minOccurs="0"> |
| OLD line(s): 77
| NEW line(s): 63
|
| OLD line(s): 79
<xsd:element name="YearPropertyWasPlacedInService" type="YearType" minOccurs="0"> | NEW line(s): 65
<xsd:element name="PlacedInServiceYr" type="YearType" minOccurs="0"> |
| OLD line(s): 86
| NEW line(s): 71
|
| OLD line(s): 88
<xsd:element name="PropUseTradeBusOrIncmProdActy" type="LineExplanationType" minOccurs="0"> | NEW line(s): 73
<xsd:element name="PropUseTrdBusOrIncmProdActyTxt" type="LineExplanationType" minOccurs="0"> |
| OLD line(s): 95
| NEW line(s): 79
|
| OLD line(s): 98
| NEW line(s): 81
|


Hi!
My name is Andrei Talaba
I'm a rising junior at Cornell University, majoring in Computer Science. I am planning on vectoring in both Software Engineering and Security & Trustworthy Systems
I started learning computer science after my friends invited me to Hack NYU 2014. After spending 48 hours learning AngelScript, and re-creating Space Invaders, I realized that I loved programming, and after taking my functional programming course at college, I realized that I absolutely loved computer science.
While most of my experience is in full stack web development, I'm trying to


Linksys Velop 2-pack tri-band mesh Wi-Fi is $100 off on Amazon
by David OhThe benefits of a mesh Wi-Fi system are numerous: better coverage, no single point of failure, modular expandability, and maintenance of a single SSID and connection throughout the home. With numerous players in this competitive field, prices have become a lot more affordable on these once very expensive mesh systems. Linksys, a well-known name among networking companies, has the Velop line, and there is a significant markdown today on one of its offerings. A two-pack of tri-band routers currently only costs $200 on Amazon, which is a saving of $100 on the usual $300 retail price.
Linksys claims two of its tri-band nodes can easily blanket strong Wi-Fi signals to multi-story homes with three to five bedrooms (up to 4,000 square feet of coverage). With tri-band connectivity speeds (867 + 867 + 400 Mbps, per node), demanding scenarios such as multiple streams of 4K media shouldn't be a problem. Each node can handle up to maximum 32 clients, so two nodes will be enough for about 60 devices, suitable for a modern home.
Should you require even more coverage later down the line, additional nodes can be added to vanquish any dead spots.
For more Black Friday deals, check out our comprehensive and frequently updated roundup.
Buy:
Amazon


During this research phase Stakeholder Interviews will help define the personas and key user scenarios which are relevant to the project.
Based on the understanding from the discovery phase, we create the storyboards to better understand the user flows and quick concept sketchbooks which can be validated with internal stakeholders.
We iterate on the design via the sketchbooks and start defining the visual signature based on branding and KPI requirements; further create a HTML clickthrough prototype which can be used for usability testing and design definition for development teams.
Working closely with the development team build the proposition and continue validation with end-users and stakeholders focused to gain deeper understanding on the gaps and needs.
To us, thinking together is synonymous to working together. We start by learning all about you as people and all about the product you’re bringing to the world. We’ll leverage our previous experience in helping great companies to help you challenge your ideas, stretch your limits to ensure that you continually exceed your own expectations.
When a product works well, it’s a beautiful thing (inside and out). The way we focus on branding, user experience and visual design is always based on three core tenets: functionality, aesthetics, and scalability. Our designers work together with our developers every single step of the way. This synchronization is fueled by a user-centric approach. We use modern techniques such as Key User Scenarios, Prototyping, and Storyboards to establish the correct User Flow. This process ensures that your user successfully complete the tasks you set out for them.
When it comes to our development team we skip over the modesty part. Our developers are incredible professionals. All are experts in their respective fields (iOS, android, Titanium, Ruby on Rails, HTML5, Node.js, Angular.js) and share a distinct passion for building brilliantly simple solutions to the most complex problems. Being really good at what we do means that we can actually communicate it to both technical and non-technical folk. That means you’re always on top of with what we’ve done, what we’re doing and what we’re up against.
As we see it, a company simply starts with a first product release. Growth is an ongoing pursuit. We help you by building integrated systems to constantly collect and interpret your user feedback and behavior. We work with you to develop solutions that meet the real user problems you’ll be up against. We manage this data to help you learn how to best prioritize new or improved functionality in subsequent releases.


There is a major problem today with the way that mobile applications are designed. Tell me, how many times have you found yourself in the following situation:
You recently picked up some contractual work with a small time company to create an iOS application. Your point of contact debriefs you on the project and functionality of the app, and all seems well with what they are asking for.   It has no external consistency with the other apps on the user's device. The components look different, the contrast of colors are different, and the navigation bar is on the top of the screen when it should be at the bottom.
I have been in this kind of situation many times, and I always express my concerns right away. "I think it all looks pretty nice, but I really think for iOS you want to put the toolbar on the bottom, not the top. Usually you put toolbars on the top for Android."
And this is where I crack up on the inside every time: "Oh, I mean, I think it looks ok, and we were actually going to use these designs for both Android and iOS," says the designer.
Let that sink in for a moment.
Would you design a car and a truck with the same standards? No, you wouldn't, and the same thought should occur when designing mobile applications for different platforms. The user expects to see a certain "flavor" of design within your app. Imagine opening your and Android app to see the glassy look and thin blue icons of an iOS app. It would take my attention away from the function of the app, and I would be wondering why the app looks like that. Just imagine the confusion for our users who have only used one type of OS for their entire lives.
Not only does the design have a chance to confuse users, but it can also make the development of the application much more challenging. In Android, the default toolbar is set at the top of the screen, with options to either set text for each tab or an icon for each tab. When a developer is tasked with positioning the toolbar at the bottom of the screen, and have each tab contain text and an image, hoops have to be jumped through. The developer needs to add invisible views to push the toolbar down, or add extra layout constraints. Custom views are needed to get the right tab design, and more than often requires some extra touch up to ensure the alignments and font sizes are correct. It is just a hassle, all to create a design effect that goes against the guidelines of the platform.
Now of course, there are always exceptions to these rules; company branding may require different fonts, color schemes, and even UI components. Larger companies can skirt around these issues by even setting standards themselves. However, when designing for any mobile platforms, designers need to take the guidelines set forth by the OS creators into account. I can't stand seeing another single design made for both iOS and Android. There are ways to fit your brand into these guidelines, and even by varying an existing design only slightly from OS to OS, you can make a mobile application that is effective for all users. Remember, as a designer, you are not designing an application that is tailored toward you, or toward your own mobile phone.
Ever find yourself in a similar situation? Even better, have you been the culprit of creating a universal design for the sake of saving time, money, and effort? Share your experiences in the comment section below.


I have Posted my four favorite projects inthis portfolio. For a full list of my repos and collabs, click github.com/SeanB333. to take you to my github profile. you can also view my Codewars profile by clicking Codewars/SeanB333.
The most important part of a project is work flow. As a 20+ year OPM, I understand the necessity of task relations and production vs progress. I have gained a great deal of experience using VSCode and Trello(linked to the github projects Khanban board) to build web apps that involve tech such as Node, React, Express, Sequelize, Mongo DB, and more
SCI-NET is a simple web scrape app that allows the user to scrape articles from thier favorite science pages and or blogs and save them to the database.
This app lets users sign in and buy, sell, and trade preserved blocks of code with other users!
A fully functional Node-CLI that allows differnt levels of product related database manipulation


{% load static %}
Tic-Tac-Toe is a long beloved classic pen and paper or board game for two players. Variations of Tic Tac Toe have been played since the Roman Empire and 3 in a row games can be traced all the way back to ancient Egypt!


Before Change
def _get_all_nodes(self):
try:
completed = os_ext.run_command("scontrol -a show -o nodes",
check=True)
except SpawnedProcessError as e:
raise JobError("could not retrieve node information") from e
node_descriptions = completed.stdout.splitlines()
After Change
def _get_all_nodes(self):
try:
completed = _run_strict("scontrol -a show -o nodes")
except SpawnedProcessError as e:
raise JobError("could not retrieve node information") from e
node_descriptions = completed.stdout.splitlines()


A pioneer in the digital media industry, Gracenote combines information, technology, services, and applications to create ingenious entertainment solutions for the global market.
From media management, enrichment, and discovery products to content identification technologies, Gracenote allows providers of digital media products and the content community to make their offerings more powerful and intuitive, enabling superior consumer experiences. Gracenote solutions integrate the broadest, deepest, and highest quality global metadata and enriched content with an infrastructure that services billions of searches a month from thousands of products used by hundreds of millions of consumers.
Gracenote customers include the biggest names in the consumer electronics, mobile, automotive, software, and Internet industries. The company's partners in the entertainment community include major music publishers and labels, prominent independents, and movie studios.
Gracenote technologies are used by leading online media services, such as Apple iTunes®, Pandora®, and Sony Music Unlimited, and by leading consumer electronics manufacturers, such as Pioneer, Philips, and Sony, and by nearly all OEMs and Tier 1s in the automotive space, such as GM, VW, Nissan, Toyota, Hyundai, Ford, BMW, Mercedes Benz, Panasonic, and Harman Becker.
For more information about Gracenote, please visit: www.gracenote.com.


| Home |
Reproduced for your convenience from RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1. Please note that portions of this document are copyrighted by The Internet Society.
| 1xx | Informational |
| 100 | Continue |
| 101 | Switching Protocols |
| 2xx | Successful |
| 200 | OK |
| 201 | Created |
| 202 | Accepted |
| 203 | Non-Authoritative Information |
| 204 | No Content |
| 205 | Reset Content |
| 206 | Partial Content |
| 3xx | Redirection |
| 300 | Multiple Choices |
| 301 | Moved Permanently |
| 302 | Found |
| 303 | See Other |
| 304 | Not Modified |
| 305 | Use Proxy |
| 306 | (Unused) |
| 307 | Temporary Redirect |
| 4xx | Client Error |
| 400 | Bad Request |
| 401 | Unauthorized |
| 402 | Payment Required |
| 403 | Forbidden |
| 404 | Not Found |
| 405 | Method Not Allowed |
| 406 | Not Acceptable |
| 407 | Proxy Authentication Required |
| 408 | Request Timeout |
| 409 | Conflict |
| 410 | Gone |
| 411 | Length Required |
| 412 | Precondition Failed |
| 413 | Request Entity Too Large |
| 414 | Request-URI Too Long |
| 415 | Unsupported Media Type |
| 416 | Requested Range Not Satisfiable |
| 417 | Expectation Failed |
| 5xx | Server Error |
| 500 | Internal Server Error |
| 501 | Not Implemented |
| 502 | Bad Gateway |
| 503 | Service Unavailable |
| 504 | Gateway Timeout |
| 505 | HTTP Version Not Supported |
Informational 1xx |
|---|
|
This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions. A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent. Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response. (For example, if a proxy adds a "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).) |
100 Continue |
|---|
|
The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code. |
101 Switching Protocols |
|---|
|
The server understands and is willing to comply with the client's request, via the Upgrade message header field (section 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response. The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features. |
Successful 2xx |
|---|
|
This class of status code indicates that the client's request was successfully received, understood, and accepted. |
200 OK |
|---|
|
The request has succeeded. The information returned with the response is dependent on the method used in the request, for example: GET an entity corresponding to the requested resource is sent in the response; HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body; POST an entity describing or containing the result of the action; TRACE an entity containing the request message as received by the end server. |
201 Created |
|---|
|
The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead. A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19. |
202 Accepted |
|---|
|
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this. The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled. |
203 Non-Authoritative Information |
|---|
|
The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK). |
204 No Content |
|---|
|
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant. If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view. The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields. |
205 Reset Content |
|---|
|
The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity. |
206 Partial Content |
|---|
|
The server has fulfilled the partial GET request for the resource.
The request MUST have included a Range header field (section 14.35)
indicating the desired range, and MAY have included an If-Range
header field (section 14.27) to make the request conditional.
The response MUST include the following header fields: - Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body. - Date - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request. A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see 13.5.4. A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses. |
Redirection 3xx |
|---|
|
This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection. Note: previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that there might be clients that implement such a fixed limitation. |
300 Multiple Choices |
|---|
|
The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location. Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise. |
301 Moved Permanently |
|---|
|
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise. The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request. |
302 Found |
|---|
|
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. |
303 See Other |
|---|
|
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable. The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303. |
304 Not Modified |
|---|
|
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields. The response MUST include the following header fields: - Date, unless its omission is required by section 14.18.1 If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly. - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional. If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response. |
305 Use Proxy |
|---|
|
The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers. Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences. |
306 (Unused) |
|---|
|
The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved. |
307 Temporary Redirect |
|---|
|
The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI. If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. |
Client Error 4xx |
|---|
|
The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user. If the client is sending data, a server implementation using TCP SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the HTTP application. |
400 Bad Request |
|---|
|
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. |
401 Unauthorized |
|---|
|
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43]. |
402 Payment Required |
|---|
|
This code is reserved for future use. |
403 Forbidden |
|---|
|
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead. |
404 Not Found |
|---|
|
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable. |
405 Method Not Allowed |
|---|
|
The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource. |
406 Not Acceptable |
|---|
|
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request. Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable. If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions. |
407 Proxy Authentication Required |
|---|
|
This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43]. |
408 Request Timeout |
|---|
|
The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time. |
409 Conflict |
|---|
|
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type. |
410 Gone |
|---|
|
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise. The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner. |
411 Length Required |
|---|
|
The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message. |
412 Precondition Failed |
|---|
|
The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended. |
413 Request Entity Too Large |
|---|
|
The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again. |
414 Request-URI Too Long |
|---|
|
The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI. |
415 Unsupported Media Type |
|---|
|
The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method. |
416 Requested Range Not Satisfiable |
|---|
|
A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.) When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content- type. |
417 Expectation Failed |
|---|
|
The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server. |
Server Error 5xx |
|---|
|
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method. |
500 Internal Server Error |
|---|
|
The server encountered an unexpected condition which prevented it from fulfilling the request. |
501 Not Implemented |
|---|
|
The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. |
502 Bad Gateway |
|---|
|
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request. |
503 Service Unavailable |
|---|
|
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response. Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection. |
504 Gateway Timeout |
|---|
|
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. Note: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. |
505 HTTP Version Not Supported |
|---|
|
The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server. |
100 Continue |
|---|
|
The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code. |
101 Switching Protocols |
|---|
|
The server understands and is willing to comply with the client's request, via the Upgrade message header field (section 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response. The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features. |
Successful 2xx |
|---|
|
This class of status code indicates that the client's request was successfully received, understood, and accepted. |
200 OK |
|---|
|
The request has succeeded. The information returned with the response is dependent on the method used in the request, for example: GET an entity corresponding to the requested resource is sent in the response; HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body; POST an entity describing or containing the result of the action; TRACE an entity containing the request message as received by the end server. |
201 Created |
|---|
|
The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead. A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19. |
202 Accepted |
|---|
|
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this. The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled. |
203 Non-Authoritative Information |
|---|
|
The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK). |
204 No Content |
|---|
|
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant. If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view. The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields. |
205 Reset Content |
|---|
|
The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity. |
206 Partial Content |
|---|
|
The server has fulfilled the partial GET request for the resource.
The request MUST have included a Range header field (section 14.35)
indicating the desired range, and MAY have included an If-Range
header field (section 14.27) to make the request conditional.
The response MUST include the following header fields: - Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body. - Date - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request. A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see 13.5.4. A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses. |
Redirection 3xx |
|---|
|
This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection. Note: previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that there might be clients that implement such a fixed limitation. |
300 Multiple Choices |
|---|
|
The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location. Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise. |
301 Moved Permanently |
|---|
|
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise. The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request. |
302 Found |
|---|
|
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. |
303 See Other |
|---|
|
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable. The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303. |
304 Not Modified |
|---|
|
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields. The response MUST include the following header fields: - Date, unless its omission is required by section 14.18.1 If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly. - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional. If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response. |
305 Use Proxy |
|---|
|
The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers. Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences. |
306 (Unused) |
|---|
|
The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved. |
307 Temporary Redirect |
|---|
|
The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI. If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. |
Client Error 4xx |
|---|
|
The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user. If the client is sending data, a server implementation using TCP SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the HTTP application. |
400 Bad Request |
|---|
|
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. |
401 Unauthorized |
|---|
|
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43]. |
402 Payment Required |
|---|
|
This code is reserved for future use. |
403 Forbidden |
|---|
|
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead. |
404 Not Found |
|---|
|
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable. |
405 Method Not Allowed |
|---|
|
The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource. |
406 Not Acceptable |
|---|
|
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request. Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable. If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions. |
407 Proxy Authentication Required |
|---|
|
This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43]. |
408 Request Timeout |
|---|
|
The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time. |
409 Conflict |
|---|
|
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type. |
410 Gone |
|---|
|
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise. The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner. |
411 Length Required |
|---|
|
The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message. |
412 Precondition Failed |
|---|
|
The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended. |
413 Request Entity Too Large |
|---|
|
The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again. |
414 Request-URI Too Long |
|---|
|
The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI. |
415 Unsupported Media Type |
|---|
|
The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method. |
416 Requested Range Not Satisfiable |
|---|
|
A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.) When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content- type. |
417 Expectation Failed |
|---|
|
The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server. |
Server Error 5xx |
|---|
|
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method. |
500 Internal Server Error |
|---|
|
The server encountered an unexpected condition which prevented it from fulfilling the request. |
501 Not Implemented |
|---|
|
The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. |
502 Bad Gateway |
|---|
|
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request. |
503 Service Unavailable |
|---|
|
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response. Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection. |
504 Gateway Timeout |
|---|
|
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. Note: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. |
505 HTTP Version Not Supported |
|---|
|
The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server. |
Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.


Find in Newspapers
contained word
headline
newspaper
Der Standard
Frankfurter Allgemeine
published after
published before
sort
relevance
size (ascending)
size (descending)
postings


Joanna Gaines dishes details about new cookbook
by Janine PuhakThe ever-honest Joanna Gaines is keeping it real as she serves up details on her forthcoming cookbook.
On Thursday, the former “Fixer Upper” star announced that her “Magnolia Table Vol. 2” is officially available for preorder, and teased some of the recipes it will include when it hits shelves in April 2020.
Following the original “Magnolia Table” tome, which was published 2018, fans of the superstar designer can look forward to her delicious takes on mushroom-gruyére quiche, chicken-pecan-asparagus casserole, zucchini-squash strata and Magnolia Press chocolate cake, among others in the text’s 145 recipes.
“What made this second experience so unique was that most of my family’s tried-and-true recipes were already shared in the first cookbook, which required us to get in the kitchen, start from scratch, and develop a whole new collection of recipes for gathering family and friends around the table,” Gaines wrote on her Magnolia blog. “I hope this second edition gives you even more reason to gather with the ones you love!”
The HGTV star got even more candid in a YouTube video released Nov. 7, showing off her culinary chops as she stirred greens in a pan, mixed mashed potatoes and iced miniature chocolate cakes.
“So my hope with this cookbook is that it really encourages and inspires people to experiment in their kitchen, and to get after it. I’ve failed multiple times but in those failings I’ve learned so much and it just kept me coming back. I never wanted to quit,” the 41-year-old said.
FOLLOW US ON FACEBOOK FOR MORE FOX LIFESTYLE NEWS
“I have fun in the kitchen now, it’s definitely become something that feels more like a gift than a chore,” Gaines continued, detailing that she hopes readers modify the recipes, if so inclined, and truly embrace the “creative” side of cooking.
“At the end of the day, it’s really about gathering your friends and family around the table. It’s those moments that make working in the kitchen, worth it, every time,” she mused.
From raising five kids to running the booming Magnolia brand empire, Gaines and her husband Chip have a special way of making it all look easy.
CLICK HERE TO GET THE FOX NEWS APP
The power couple, parents to Drake, 14, Ella Rose, 13, Duke, 11, Emmie Kay, 9, and Crew, 1, are currently gearing up to launch their cable network – a joint venture with Discovery – in October 2020.


Lists FAQ
1. How do I index a nested list? For example if I want to grab 2 from [1,1,[1,2]]?
You would just add another set of brackets for indexing the nested list, for example: my_list[2][1] . We'll discover later on more nested objects and you will be quizzed on them later!


This box uses opacity
This box has a background color with an alpha channel
.box1 { background-color: #000; color: #fff; opacity: .5; } .box2 { background-color: rgba(0,0,0,.5); color: #fff; }
This box uses opacity
This box has a background color with an alpha channel


Welcome to GitHub Pages.
This is an Encrypted Database Framework Distribution System.
Designer Templates
We are Developer Hub. We develop website, software and more.
Authors and Contributors
This page Develop by @ooastrap
Support or Contact
Having trouble with Pages? Check out our documentation or contact support and we’ll help you sort it out.


Class UserControllerApi
Represents a collection of functions to interact with the API endpoints
Inherited Members
Namespace: mailslurp.Api
Assembly: mailslurp.dll
Syntax
public class UserControllerApi : IUserControllerApi, IUserControllerApiSync, IUserControllerApiAsync, IApiAccessor
Constructors
View SourceUserControllerApi()
Initializes a new instance of the UserControllerApi class.
Declaration
public UserControllerApi()
UserControllerApi(Configuration)
Initializes a new instance of the UserControllerApi class using Configuration object
Declaration
public UserControllerApi(Configuration configuration)
Parameters
| Type | Name | Description |
|---|---|---|
| Configuration | configuration | An instance of Configuration |
UserControllerApi(ISynchronousClient, IAsynchronousClient, IReadableConfiguration)
Initializes a new instance of the UserControllerApi class using a Configuration object and client instance.
Declaration
public UserControllerApi(ISynchronousClient client, IAsynchronousClient asyncClient, IReadableConfiguration configuration)
Parameters
| Type | Name | Description |
|---|---|---|
| ISynchronousClient | client | The client interface for synchronous API access. |
| IAsynchronousClient | asyncClient | The client interface for asynchronous API access. |
| IReadableConfiguration | configuration | The configuration object. |
UserControllerApi(string)
Initializes a new instance of the UserControllerApi class.
Declaration
public UserControllerApi(string basePath)
Parameters
| Type | Name | Description |
|---|---|---|
| string | basePath |
Properties
View SourceAsynchronousClient
The client for accessing this underlying API asynchronously.
Declaration
public IAsynchronousClient AsynchronousClient { get; set; }
Property Value
| Type | Description |
|---|---|
| IAsynchronousClient |
Client
The client for accessing this underlying API synchronously.
Declaration
public ISynchronousClient Client { get; set; }
Property Value
| Type | Description |
|---|---|
| ISynchronousClient |
Configuration
Gets or sets the configuration object
Declaration
public IReadableConfiguration Configuration { get; set; }
Property Value
| Type | Description |
|---|---|
| IReadableConfiguration | An instance of the Configuration |
ExceptionFactory
Provides a factory method hook for the creation of exceptions.
Declaration
public ExceptionFactory ExceptionFactory { get; set; }
Property Value
| Type | Description |
|---|---|
| ExceptionFactory |
Methods
View SourceGetBasePath()
Gets the base path of the API client.
Declaration
public string GetBasePath()
Returns
| Type | Description |
|---|---|
| string | The base path |
GetJsonPropertyAsString(string, object, int)
Utility function to extract properties from JSON objects in language where this is cumbersome.
Declaration
public string GetJsonPropertyAsString(string property, object body, int operationIndex = 0)
Parameters
| Type | Name | Description |
|---|---|---|
| string | property | JSON property name or dot separated path selector such as |
| object | body | |
| int | operationIndex | Index associated with the operation. |
Returns
| Type | Description |
|---|---|
| string | string |
Exceptions
| Type | Condition |
|---|---|
| ApiException | Thrown when fails to make API call |
GetJsonPropertyAsStringAsync(string, object, int, CancellationToken)
Utility function to extract properties from JSON objects in language where this is cumbersome.
Declaration
public Task<string> GetJsonPropertyAsStringAsync(string property, object body, int operationIndex = 0, CancellationToken cancellationToken = default)
Parameters
| Type | Name | Description |
|---|---|---|
| string | property | JSON property name or dot separated path selector such as |
| object | body | |
| int | operationIndex | Index associated with the operation. |
| CancellationToken | cancellationToken | Cancellation Token to cancel the request. |
Returns
| Type | Description |
|---|---|
| Task<string> | Task of string |
Exceptions
| Type | Condition |
|---|---|
| ApiException | Thrown when fails to make API call |
GetJsonPropertyAsStringWithHttpInfo(string, object, int)
Utility function to extract properties from JSON objects in language where this is cumbersome.
Declaration
public ApiResponse<string> GetJsonPropertyAsStringWithHttpInfo(string property, object body, int operationIndex = 0)
Parameters
| Type | Name | Description |
|---|---|---|
| string | property | JSON property name or dot separated path selector such as |
| object | body | |
| int | operationIndex | Index associated with the operation. |
Returns
| Type | Description |
|---|---|
| ApiResponse<string> | ApiResponse of string |
Exceptions
| Type | Condition |
|---|---|
| ApiException | Thrown when fails to make API call |
GetJsonPropertyAsStringWithHttpInfoAsync(string, object, int, CancellationToken)
Utility function to extract properties from JSON objects in language where this is cumbersome.
Declaration
public Task<ApiResponse<string>> GetJsonPropertyAsStringWithHttpInfoAsync(string property, object body, int operationIndex = 0, CancellationToken cancellationToken = default)
Parameters
| Type | Name | Description |
|---|---|---|
| string | property | JSON property name or dot separated path selector such as |
| object | body | |
| int | operationIndex | Index associated with the operation. |
| CancellationToken | cancellationToken | Cancellation Token to cancel the request. |
Returns
| Type | Description |
|---|---|
| Task<ApiResponse<string>> | Task of ApiResponse (string) |
Exceptions
| Type | Condition |
|---|---|
| ApiException | Thrown when fails to make API call |
GetUserInfo(int)
Get account information for your user
Declaration
public UserInfoDto GetUserInfo(int operationIndex = 0)
Parameters
| Type | Name | Description |
|---|---|---|
| int | operationIndex | Index associated with the operation. |
Returns
| Type | Description |
|---|---|
| UserInfoDto | UserInfoDto |
Exceptions
| Type | Condition |
|---|---|
| ApiException | Thrown when fails to make API call |
GetUserInfoAsync(int, CancellationToken)
Get account information for your user
Declaration
public Task<UserInfoDto> GetUserInfoAsync(int operationIndex = 0, CancellationToken cancellationToken = default)
Parameters
| Type | Name | Description |
|---|---|---|
| int | operationIndex | Index associated with the operation. |
| CancellationToken | cancellationToken | Cancellation Token to cancel the request. |
Returns
| Type | Description |
|---|---|
| Task<UserInfoDto> | Task of UserInfoDto |
Exceptions
| Type | Condition |
|---|---|
| ApiException | Thrown when fails to make API call |
GetUserInfoWithHttpInfo(int)
Get account information for your user
Declaration
public ApiResponse<UserInfoDto> GetUserInfoWithHttpInfo(int operationIndex = 0)
Parameters
| Type | Name | Description |
|---|---|---|
| int | operationIndex | Index associated with the operation. |
Returns
| Type | Description |
|---|---|
| ApiResponse<UserInfoDto> | ApiResponse of UserInfoDto |
Exceptions
| Type | Condition |
|---|---|
| ApiException | Thrown when fails to make API call |
GetUserInfoWithHttpInfoAsync(int, CancellationToken)
Get account information for your user
Declaration
public Task<ApiResponse<UserInfoDto>> GetUserInfoWithHttpInfoAsync(int operationIndex = 0, CancellationToken cancellationToken = default)
Parameters
| Type | Name | Description |
|---|---|---|
| int | operationIndex | Index associated with the operation. |
| CancellationToken | cancellationToken | Cancellation Token to cancel the request. |
Returns
| Type | Description |
|---|---|
| Task<ApiResponse<UserInfoDto>> | Task of ApiResponse (UserInfoDto) |
Exceptions
| Type | Condition |
|---|---|
| ApiException | Thrown when fails to make API call |


PAYBACK (director: Brian Helgeland; cast:(Porter) Mel Gibson, (Val) Gregg Henry, (Rosie) Maria Bello, (Stegman) David Paymer,(Lynn) Deborah Kara Unger, (Carter) William Devane, (Bronson) Kris Kristofferson, (Mr. Fairfax) James Coburn, (Crooked Cop) Bill Duke, 1999)
What we have, is a very cleverly done film, that is in it for the box-office and as an entertainment only film, and it should accomplish both aims, at least, entertainment wise, it is first-rate. It is a good mindless, violent flick for Americans to take their mind off the more serious things occuring at the time this movie opened, such as the political scandal and impeachment hearings involving our Prez and his lady intern (and, you know how serious that stuff was).
To get into the spirit of the film, you must suspend your belief in logic and accept this as a hero fantasy story, with the hero being a tainted one, basically fighting for his own pride and perverted sense of ethics, as he figures his life is worth $70, 000, that being the figure he is owed by his partner in crime, Val (Gregg), a sado-masochist, with no redeeming human qualities, who along with Porter (Mel), has robbed an Oriental crime family to get the unsavory dough, before he double-crossed Porter, and supposedly had him killed. But do remember, the bad hero, is not all that bad, he is Mel, the charming hero of countless adventure films, a guy who is full of good looks and charm, someone audiences love to like, and will plunk down their money to see his films in huge numbers. He also does the voice-over ala noir style, in a deep laconic voice, you know, like a Sam Spade would do it. The voice-over reassured me that he will live through the film (that's good, because knowing him, he will be in every scene of this flick, and therefore I'm assured that I will be getting my money's worth of Mel. You see, I don't really care what happens to his character in this flick, per se, since he is as unreal as the ones you find in the cartoons. What I care about is being entertained, by golly, golly, golly, gee !).
PAYBACK rips off the way a noir film is shot and looks, (or maybe, in a certain sense, pays it homage!!!) and does it with pizzazz. The big city it chooses for its locale is Chicago, with its tall buildings and el trains, adding a dark shade to its story. The only thing it fails to pick up from those great b/w films mood pieces of edginess from the 40s and 50s, is that their heroes were really underdogs, they were fighting the system, not out for their own ends and vanity only. This little difference is easy to ignore, but it is bothersome when I see how close Mel came to sniffing out the essence of a noir film. But I'm glad to report, ever so close, but no cigar, tough guy. You just can't imitate that secret ingredient without being into the real thing.  You were both great to look at on screen, you played your hands well, and most importantly, I enjoyed the film, it had a lightness to it that made it very appealing.
Needless to say, there was not much to the plot for this stylish film, but for those of you who want to know the story line, this is a pure revenge film. Porter after being set-up by his junkie wife Lynn (Deborah), and Val, who needs a $130, 000 to square things with the "outfit" and get back into the organization, where he can really get good money and protection from the mob...The action scenes of this heist are super. Porter notices that the gang is not wearing their seat belts, so on their rounds, when they are carrying the loot, he crashes head-on to them, killing them and then robbing them of the loot. Then Val does his double-cross, as Porter's wife shoots her hubby, taking all the money, which happens to be $140, 000. That is why our hero insists on only getting $70, 000 back, the sum he believes he is ethically owed for the work he did. This gag lends a much welcomed humor to what could have been just a pointless actioner. At least, the filmmakers are having fun with this one, and it shows.
For the remainder of this slick film, Porter is either getting beat up or doing the beatings himself. In between there are assorted killings the traditional way, with a heater. But there is also a car full of mobsters getting blown up and some get blown up via the phone. There is plenty of action, so don't worry you don't have to think of anything when you are watching this flick, everything moves at break-neck speed. A duo of corrupt cops get into the act, one black the other white, very political correct, I must say. These filmmakers have a great eye for detail. And there is a sleaze ball drug dealer (Paymer), the one who sells bad heroin to Porter's dear wife. He turns out to be the man Porter uses to contact Val upon his return from the dead. Then there is the Oriental gang, and their interest turns to Porter when they are tipped off that he robbed them. So, all-in-all, you have a lot of good action scenes going down, a lot of funny one-liners (I laughed out loud when Porter said, if I was any dumber I would have become a cop.  I, especially, liked seeing Devane, he is a throwback to the old noir foils. There is also an homage scene or a rip off, which ever you prefer, it doesn't matter to me, when Porter rips the earring off a drug dealer's ear, taking a chunk of his ear with it. You can't help remembering Roman Polansky did that in CHINATOWN, a true modern noir film, a film that caught the essence of that genre.
The filmmakers are first time director and former screen writer of L.A. CONFIDENTIAL, Brian Helgeland. The film is based on a novel, THE HUNTER, by Richard Stark. The film works for all the above reasons, and most of all it works, because Mel is great for the part.
REVIEWED ON 3/7/99 GRADE: C+
© ALL RIGHTS RESERVED DENNIS SCHWARTZ
Dennis Schwartz (Movie Reviews<EMAIL_ADDRESS>http:www.sover.net/~ozus
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Loads object models from file and renders using VBOs/VAOs.
More...
#include <modelLoader3.hpp>
|
|
| ModelLoader () |
| | Creates an empty model.
|
| |
| | ModelLoader (const char *filename) |
| | Loads a model from the given file. More...
|
| |
|
| ~ModelLoader () |
| | Frees memory associated with model on both CPU and GPU.
|
| |
| bool | loadModelFile (const char *filename, bool INFO=true, bool ERRORS=true) |
| | Loads a model from the given file. More...
|
| |
| bool | draw (GLint positionLocation, GLint normalLocation=-1, GLint texCoordLocation=-1, GLint matDiffLocation=-1, GLint matSpecLocation=-1, GLint matShinLocation=-1, GLint matAmbLocation=-1, GLenum diffuseTexture=GL_TEXTURE0) |
| | Renders a model. More...
|
| |
Loads object models from file and renders using VBOs/VAOs.
◆ ModelLoader()
| CSCI441::ModelLoader::ModelLoader |
( |
const char * |
filename | ) |
|
Loads a model from the given file.
- Parameters
-
| const | char* filename - file to load model from |
◆ disableAutoGenerateNormals()
| void CSCI441::ModelLoader::disableAutoGenerateNormals |
( |
| ) |
|
|
static |
Disable autogeneration of vertex normals.
If an object model does not contain vertex normal data, then normals will be computed based on the cross product of vertex winding order.
- Note
- Must be called prior to loading in a model from file
-
No normals are generated by default
◆ draw()
| bool CSCI441::ModelLoader::draw |
( |
GLint |
positionLocation, |
|
|
GLint |
normalLocation = -1 , |
|
|
GLint |
texCoordLocation = -1 , |
|
|
GLint |
matDiffLocation = -1 , |
|
|
GLint |
matSpecLocation = -1 , |
|
|
GLint |
matShinLocation = -1 , |
|
|
GLint |
matAmbLocation = -1 , |
|
|
GLenum |
diffuseTexture = GL_TEXTURE0 |
|
) |
| |
Renders a model.
- Parameters
-
| GLint | positionLocation - attribute location of vertex position |
| GLint | normalLocation - attribute location of vertex normal |
| GLint | texCoordLocation - attribute location of vertex texture coordinate |
| GLint | matDiffLocation - attribute location of material diffuse component |
| GLint | matSpecLocation - attribute location of material specular component |
| GLint | matShinLocation - attribute location of material shininess component |
| GLint | matAmbLocation - attribute location of material ambient component |
| GLenum | diffuseTexture - texture number to bind diffuse texture map to |
- Returns
- true if draw succeeded, false otherwise
◆ enableAutoGenerateNormals()
| void CSCI441::ModelLoader::enableAutoGenerateNormals |
( |
| ) |
|
|
static |
Enable autogeneration of vertex normals.
If an object model does not contain vertex normal data, then normals will be computed based on the cross product of vertex winding order.
- Note
- Must be called prior to loading in a model from file
◆ loadModelFile()
| bool CSCI441::ModelLoader::loadModelFile |
( |
const char * |
filename, |
|
|
bool |
INFO = true , |
|
|
bool |
ERRORS = true |
|
) |
| |
Loads a model from the given file.
- Parameters
-
| const | char* filename - file to load model from |
| bool | INFO - flag to control if informational messages should be displayed |
| bool | ERRORS - flag to control if error messages should be displayed |
- Returns
- true if load succeeded, false otherwise
The documentation for this class was generated from the following file: